答:
Verbosity being a tendency to use extensive amounts of text, and Terseness the use of very little text...

Verbosity is bad because:

it introduces more opportunity for typographical error

it makes it harder to read code on screen or paper, and/or enter on punchcard

this increases debug times

this makes comprehension of code for upgrade/maintenance harder

this can lead to unintended code duplication

it increases the likelihood of syntax error somewhat

it decreases coding flexibility, in that, most verbose languages are highly structured and don't have multiple ways to say the same thing.

it increases coding and compilation times

it can take more storage space.

A certain level of verbosity is essential for clarity, however...

a minimal level of Verbosity is good because:

it is easier for humans to read and attach semantic value to than purely symbolic code

In variable and function naming, it makes it easier to debug, port, and maintain code

in base level language operations and keywords of complex languages, it leads to fewer incorrect operation/keyword assignments.

Some wonderful examples of overly terse commands for many people include the old BASIC standbys of val(x$), str$(x), and chr$(x)... return a number from its string representation, return a string for a number, and return a single character having ascii value x as a string.

Or the C/C++  pointer and by reference operators & and * versus the BASIC byref keyword. In C/C++, I can have a variable X, and a pass a pointer to that variable, but I have to remember which is the pointer and which is the "use pointer as the variable it points to"; in basic, I simply pass the reference with a byref keyword in the function call, which is more clear, but less flexible:

```<code>def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)
</code>```

In this code, x's contents get modified due to the byref flag. Some flavors allow byref at call, others in definition, some in either.

The verbosity is important for casual programmers to be able to use the symbolism easier; BASIC or python are more human readable and more verbose than C/C++, and thus much more useful for casual programmers; the terseness of C/C++ makes it much better for more experienced programmers, who need to see more code and more complex code at one screenful, but have had to learn the various symbolic structure conventions. At the far end is APL, which is almost completely human unreadable.

An intimately related issue is clarity - terse code is often unclear, and excessively verbose code (as in AppleScript) can be equally unclear. Familiarity with a given language increases the clarity of terse code within that language - a raw beginner, facing C++ code is likely to be able to parse only the formulae, and even much functional BASIC or Python code is too terse for comprehension, but applescript can be puzzled out, generally, without recourse to language dictionaries. The least clear I've encountered without intentional obfuscation is Inform 7...

In the olden days

Another important consideration in the past, but one that is no longer as important for the hobby coder, is operation and storage space. (It's still vital at the high end.) Keeping in mind that many languages were interpreted, especially BASIC flavors, and many more were run-time compiled, code space was important, especially when disks only held 128KiB, and individual punchcards only 80B.

Several solutions existed - tokenization was extremely common in BASIC; the individual language keywords were reduced to a 1 or 2 byte word in either the upper 128 or the control character space. Tokenization lead also to bytecode compilation (as in Inform and the Z-Machine).

Multiple object file compilation and linking also was used to get around space limitations. A 100KiB Pascal code section might compile to only 5KiB; by linking multiple compiled files, one could build massive applications without having access to large format drives (remembering that 10MiB was astonishingly large, and buy a new car expensive).

More terse languages, however, got more code into a given chunk of both disk and ram, and thus compiled larger chunks at a time. Keeping in mind: "minicomputers" of the early 1970's might have only 64KiB of ram (the Honeywell 800 had a base install of 4 banks each of 2048 words of 8B each). APL and similar symbolic languages approached 1B per instruction plus its operands, versus the much larger 3B-10B per instruction plus operands. (It was a nightmare to type onto punchcards, especially since the symbols were essentially a font on type-ball, and many cardpunches didn't have the symbols on the keys...)

Also, keep in mind that cards could not be erased... and many programs were entered on cards. While not individually expensive, the more compressed your code could be on the card, the fewer you needed, and the larger the programs could be, or the less expensive. This is part of the reason BASIC has a concatenation of multiple instructions per line in most flavors - it was introduced to save on punch cards. (Or so says my Vax Basic programming text.) While I've not programmed for a card-reader, I've done the card punching for a Honeywell 800 in FORTRAN, BASIC, APL, and a couple other highly symbolic languages.

Body:
Verbosity being a tendency to use extensive amounts of text, and Terseness the use of very little text...

Verbosity is bad because:

it introduces more opportunity for typographical error

it makes it harder to read code on screen or paper, and/or enter on punchcard

this increases debug times

this makes comprehension of code for upgrade/maintenance harder

this can lead to unintended code duplication

it increases the likelihood of syntax error somewhat

it decreases coding flexibility, in that, most verbose languages are highly structured and don't have multiple ways to say the same thing.

it increases coding and compilation times

it can take more storage space.

A certain level of verbosity is essential for clarity, however...

a minimal level of Verbosity is good because:

it is easier for humans to read and attach semantic value to than purely symbolic code

In variable and function naming, it makes it easier to debug, port, and maintain code

in base level language operations and keywords of complex languages, it leads to fewer incorrect operation/keyword assignments.

Some wonderful examples of overly terse commands for many people include the old BASIC standbys of val(x$), str$(x), and chr$(x)... return a number from its string representation, return a string for a number, and return a single character having ascii value x as a string.

Or the C/C++  pointer and by reference operators & and * versus the BASIC byref keyword. In C/C++, I can have a variable X, and a pass a pointer to that variable, but I have to remember which is the pointer and which is the "use pointer as the variable it points to"; in basic, I simply pass the reference with a byref keyword in the function call, which is more clear, but less flexible:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

In this code, x's contents get modified due to the byref flag. Some flavors allow byref at call, others in definition, some in either.

The verbosity is important for casual programmers to be able to use the symbolism easier; BASIC or python are more human readable and more verbose than C/C++, and thus much more useful for casual programmers; the terseness of C/C++ makes it much better for more experienced programmers, who need to see more code and more complex code at one screenful, but have had to learn the various symbolic structure conventions. At the far end is APL, which is almost completely human unreadable.

An intimately related issue is clarity - terse code is often unclear, and excessively verbose code (as in AppleScript) can be equally unclear. Familiarity with a given language increases the clarity of terse code within that language - a raw beginner, facing C++ code is likely to be able to parse only the formulae, and even much functional BASIC or Python code is too terse for comprehension, but applescript can be puzzled out, generally, without recourse to language dictionaries. The least clear I've encountered without intentional obfuscation is Inform 7...

In the olden days

Another important consideration in the past, but one that is no longer as important for the hobby coder, is operation and storage space. (It's still vital at the high end.) Keeping in mind that many languages were interpreted, especially BASIC flavors, and many more were run-time compiled, code space was important, especially when disks only held 128KiB, and individual punchcards only 80B.

Several solutions existed - tokenization was extremely common in BASIC; the individual language keywords were reduced to a 1 or 2 byte word in either the upper 128 or the control character space. Tokenization lead also to bytecode compilation (as in Inform and the Z-Machine).

Multiple object file compilation and linking also was used to get around space limitations. A 100KiB Pascal code section might compile to only 5KiB; by linking multiple compiled files, one could build massive applications without having access to large format drives (remembering that 10MiB was astonishingly large, and buy a new car expensive).

More terse languages, however, got more code into a given chunk of both disk and ram, and thus compiled larger chunks at a time. Keeping in mind: "minicomputers" of the early 1970's might have only 64KiB of ram (the Honeywell 800 had a base install of 4 banks each of 2048 words of 8B each). APL and similar symbolic languages approached 1B per instruction plus its operands, versus the much larger 3B-10B per instruction plus operands. (It was a nightmare to type onto punchcards, especially since the symbols were essentially a font on type-ball, and many cardpunches didn't have the symbols on the keys...)

Also, keep in mind that cards could not be erased... and many programs were entered on cards. While not individually expensive, the more compressed your code could be on the card, the fewer you needed, and the larger the programs could be, or the less expensive. This is part of the reason BASIC has a concatenation of multiple instructions per line in most flavors - it was introduced to save on punch cards. (Or so says my Vax Basic programming text.) While I've not programmed for a card-reader, I've done the card punching for a Honeywell 800 in FORTRAN, BASIC, APL, and a couple other highly symbolic languages.


问:
Strategy for restoring state via URL in web apps
This is a question about modern web apps, where a single page is loaded, and all subsequent navigation is done by XHR calls and modifying the DOM.

We can use libraries that manipulate the hash string, which let us navigate by URL and support the back/forward buttons.

But to use those libraries, we need to be able to move the UI from any one state to any other. Is there a good strategy for moving between UI states, that also allows them to be restored from scratch when you load a new URL?

In a complex app, you might have a lot of different states. You don't want to reload the entire UI each time you change states. But you also don't want to require separate methods for moving from every state to every every state.

Typically we need to:

Restore a state from scratch, when you enter a new URL or hit Reload.

Move from one state to another, when you use the Back/Forward buttons.

Move from one state to another, when you perform an action within your app (like clicking a link).

Move to certain states that shouldn't be added to the history, like ones that appear after form submissions.

Move to some states that are built on the previous state, like a drill-down list.

When you perform actions within your app, there's the additional question of which comes first:

Do you change the URL, listen for the URL change, and change your state in response to it?

Or do you change your state, then change the URL, but don't do anything in response?

Does anyone have some experience to share on this topic?

答:
You'll want to change the url, listen for changes to the url, and change the state of the page in response to url changes. This way when the user reloads, hits the back button, or performs an action on the page, the same code will be handling the page's state changes.

The code that handles the state changes can look at the current state of the page, compare that to the new requested state of the page, and perform only the actions needed for the parts of the page that have changed.

ContentLicense: CC BY-SA 3.0


问:
Why is a small fixed vocabulary seen as an advantage to RESTful services?
So, a RESTful service has a fixed set of verbs in its vocabulary. A RESTful web service takes these from the HTTP methods. There are some supposed advantages to defining a fixed vocabulary, but I don't really grasp the point. Maybe someone can explain it.

Why is a fixed vocabulary as outlined by REST better than dynamically defining a vocabulary for each state? For example, object oriented programming is a popular paradigm. RPC is described to define fixed interfaces, but I don't know why people assume that RPC is limited by these contraints. We could dynamically specify the interface just as a RESTful service dynamically describes its content structure.

REST is supposed to be advantageous in that it can grow without extending the vocabulary. RESTful services grow dynamically by adding more resources. What's so wrong about extending a service by dynamically specifying a per-object vocabulary? Why don't we just use the methods that are defined on our objects as the vocabulary and have our services describe to the client what these methods are and whether or not they have side effects?

Essentially I get the feeling that the description of a server side resource structure is equivalent to the definition of a vocabulary, but we are then forced to use the limited vocabulary in which to interact with these resources.

Does a fixed vocabulary really decouple the concerns of the client from the concerns of the server? I surely have to be concerned with some configuration of the server, this is normally resource location in RESTful services. To complain at the use of a dynamic vocabulary seems unfair because we have to dynamically reason how to understand this configuration in some way anyway. A RESTful service describes the transitions you are able to make by identifying object structure through hypermedia.

I just don't understand what makes a fixed vocabulary any better than any self-describing dynamic vocabulary, which could easily work very well in an RPC-like service. Is this just a poor reasoning for the limiting vocabulary of the HTTP protocol?

Reflection

Just to clarify my thoughts a little better than I have done. Suppose you are designing any general purpose API, maybe not even web facing. Would you be happy if someone said you can only use these method names on your objects? REST isn't restricted to HTTP, but consider the situation where every API you write, web facing or otherwise simply consisted of objects containing GET POST PUT and DELETE methods. So that object.foo method you wanted to define isn't possible. You have to define a new object called foo, and call its GET method. That's essentially how REST works, and it makes me a little uncomfortable to think about it. You don't have any better generic understanding of what foo does, you were just forced to create a new object for what is essentially a method on a parent object. Furthermore your API is no less complex, you have just hidden interface complexity by creating more objects. RESTful web services force us to adopt an interface which may or may not be sufficient in the context of the API we are exposing. Perhaps there is a good reason for doing this with web facing APIs, but a good reason to not adopt standard interfaces for every object in every general purpose API. A practical example would be appreciated.

答:
The essential idea is that complexity is expressed through the resource representation, and so additional verbs are not needed. As some have put it - "In REST, nouns are good, verbs are bad."

If you look at the four REST verbs, they can be mapped to the basic CRUD operations, essentially allowing you to do whatever you want with your resources. That is -

POST   - Create the resource

GET    - Read the resource

PUT    - Update the resource

DELETE - Delete the resource

What else do you need?


问:
Is this common amongst many languages?
In C++, the integer variable bar evaluates to 1 in this code

```<code>int foo = 0;
int bar = ++foo;
</code>```

and 0 in this code

```<code>int foo = 0;
int bar = foo++;
</code>```

Is this behavior prevalent in most popular languages?

答:
The C-like languages, such as C++, Java, and C# all have this behavior.

The definitely not C-like languages such as ruby or python typically don't have an increment or decrement operator whatsoever.

So many popular languages do have this behavior, but other popular languages don't have those operators at all.

Title: Is this common amongst many languages?


答:
Because a professional programmer anticipates hundreds, if not thousands of method names otherwise.  What seems pointless at a smaller small can be a very big deal as the application becomes bigger.

Because there's no need for standards about method names when they are already defined.

Because the main aim of code is be readable without such additional translations.

Because it encourages and aids in the identification of 'when' another class should be broken out.

When you take over code it's reasonable and actually possible to understand what and how it does it much quicker.

It provides a common vocabulary and thus level of abstraction so you can focus on other details and see patterns.

It makes finding bugs easier as common code and approaches be easily be checked.

When you're working with multiple 'layers' such as one does in web development, knowing what urls match to which action names is very handy for debugging.

Overall you don't 'always' need it, but like most standards, it makes a lot of sense to aim to try to use it!

Title: Why is a small fixed vocabulary seen as an advantage to RESTful services?

Body:
So, a RESTful service has a fixed set of verbs in its vocabulary. A RESTful web service takes these from the HTTP methods. There are some supposed advantages to defining a fixed vocabulary, but I don't really grasp the point. Maybe someone can explain it.

Why is a fixed vocabulary as outlined by REST better than dynamically defining a vocabulary for each state? For example, object oriented programming is a popular paradigm. RPC is described to define fixed interfaces, but I don't know why people assume that RPC is limited by these contraints. We could dynamically specify the interface just as a RESTful service dynamically describes its content structure.

REST is supposed to be advantageous in that it can grow without extending the vocabulary. RESTful services grow dynamically by adding more resources. What's so wrong about extending a service by dynamically specifying a per-object vocabulary? Why don't we just use the methods that are defined on our objects as the vocabulary and have our services describe to the client what these methods are and whether or not they have side effects?

Essentially I get the feeling that the description of a server side resource structure is equivalent to the definition of a vocabulary, but we are then forced to use the limited vocabulary in which to interact with these resources.

Does a fixed vocabulary really decouple the concerns of the client from the concerns of the server? I surely have to be concerned with some configuration of the server, this is normally resource location in RESTful services. To complain at the use of a dynamic vocabulary seems unfair because we have to dynamically reason how to understand this configuration in some way anyway. A RESTful service describes the transitions you are able to make by identifying object structure through hypermedia.

I just don't understand what makes a fixed vocabulary any better than any self-describing dynamic vocabulary, which could easily work very well in an RPC-like service. Is this just a poor reasoning for the limiting vocabulary of the HTTP protocol?

Reflection

Just to clarify my thoughts a little better than I have done. Suppose you are designing any general purpose API, maybe not even web facing. Would you be happy if someone said you can only use these method names on your objects? REST isn't restricted to HTTP, but consider the situation where every API you write, web facing or otherwise simply consisted of objects containing GET POST PUT and DELETE methods. So that object.foo method you wanted to define isn't possible. You have to define a new object called foo, and call its GET method. That's essentially how REST works, and it makes me a little uncomfortable to think about it. You don't have any better generic understanding of what foo does, you were just forced to create a new object for what is essentially a method on a parent object. Furthermore your API is no less complex, you have just hidden interface complexity by creating more objects. RESTful web services force us to adopt an interface which may or may not be sufficient in the context of the API we are exposing. Perhaps there is a good reason for doing this with web facing APIs, but a good reason to not adopt standard interfaces for every object in every general purpose API. A practical example would be appreciated.


问:
How does a web browser save passwords?
How do current web browsers (or mobile mail clients and any software in general) save user passwords? All answers about storing passwords say we should store only hashes, not the password themselves. But I'm having a hard time searching the web trying to find the best techniques to store passwords when we know we will need them in plain text later on — without storing them in plain text, without using a weak encryption (known key) and without asking the user for a master password. Any ideas?</p>

答: These programs need the password in clear text (they need to submit it when requested). It is therefore stored as plain text. Many browser allow to encrypt all the stored passwords with a master password (asked only once).</p>

Title: How does a web browser save passwords?


答:
The passwords are stored in plain text, unless a master password is used.

When people tell that you must store only hashes of passwords, they are talking about server-side storage, not client-side.

Server-side

When you have your own website when the users can register/logon with their passwords, you don't need (and must never) store the passwords themselves:

You don't need to store plain passwords, because you only have to verify that the password used during a logon matches the password given by the user while registering. You can do it with hashes, since different passwords would have different hashes¹.

You must not store plain passwords. What if your website is hacked? Moreover, many people reuse same passwords again and again, so you practically give to any hacker the ability to access your users Facebook account, mail account, etc.

Client-side

Browsers are different. They store the passwords on client machine, and must have an original password, not a hash.

This means that those passwords are stored in plain text in most cases.

Security-wise, it doesn't matter too much. Those passwords are stored in a directory which belongs to the user account. This means that it's up to the operating system (and to the user) to properly configure the permissions to the users files, and to restrict the access to the file which contains the passwords to the user himself.

User experience wise, this is the easiest thing to do. Another possibility is to encrypt those passwords by a master password, in which case the user would have to provide the master password every time he opens the browser. I'm pretty sure most users would never enjoy that.

If the master password is stored somewhere, the same problem arises: if you store the master password in plain text, what's the point? If you encrypt it, you must have a master-master password.

Sync

Note that most browsers enable the users to sync their data across multiple machines. The sync uses a remote server to store the cookies, history, bookmarks and passwords. For example, Chrome uses Google servers to store this data.

In this case, the passwords are never stored in plain text on sync servers, otherwise, it would be a security issue. In Chrome, you have to choose the master password for sync (or use the one from your Google account). This master password will be used to encrypt the passwords (always), and other data like the history or the bookmarks (optional).

¹ For the sake of simplicity, you can imagine that the different passwords cannot have same hashes. In theory, this is wrong, since collisions may exist. In practice, if you use a strong hash algorithm, like SHA-256, you can neglect the risk of collision for a website even with millions of registered users. Things are different if you use an obsolete and depreciated hash algorithm, like MD5.

Title: How does a web browser save passwords?

Body: How do current web browsers (or mobile mail clients and any software in general) save user passwords? All answers about storing passwords say we should store only hashes, not the password themselves. But I'm having a hard time searching the web trying to find the best techniques to store passwords when we know we will need them in plain text later on — without storing them in plain text, without using a weak encryption (known key) and without asking the user for a master password. Any ideas?</p>


问:
Improving performance for web scraping code
I have a website in which the code scrapes other websites for getting the accurate data. While the code works good but there a decent lag in performance because the code firsts downloads the html stream from various sites(some times 9 websites), extracts the relative part and then renders the html page.

What should I do to get an optimal performance. Should I change from shared hosting (godaddy) to my own server or it has nothing to do with my hosting and I need to make changes to my code?

答:
API/CSV

Ask those websites if they provide an API, or, if you don't need an up-to-date information or the information you need doesn't change frequently, if they can sell/give you for free the data itself (for example in an CSV file). Some small websites may have fancier ways to access data, like a CSV file for the older information, and an RSS feed for the changed one.

Those websites would probably be happy to help you, since providing you with an API would reduce their own CPU and bandwidth usage by you.

Profile

Screen scrapping is really ugly when it comes to performance and scaling. You may be limited by:

your machine performance, since parsing, sometimes an invalid HTML file, takes time,

your network speed,

their network speed usage, i.e. how fast can you access the pages of their website depending on the restrictions they set, like the DOS protection and the number of requests per second for screen scrappers and search engine crawlers,

their machine performance: if they spend 500 ms. to generate every page, you can't do anything to reduce this delay.

If, despite your requests to them, those websites cannot provide any convenient way to access their data, but they give you a written consent to screen scrape their website, then profile your code to determine the bottleneck. It may be the internet speed. It may be your database queries. It may be anything.

For example, you may discover that you spend too much time finding with regular expressions the relevant information in the received HTML. In that case, you would want to stop doing it wrong and use a parser instead of regular expressions, then see how this improve the performance.

You may also find that the bottleneck is the time the remote server spends generating every page. In this case, there is nothing to do: you may have the fastest server, the fastest connection and the most optimized code, the performance will be the same.

Do things in parallel:

Remember to use parallel computing wisely and to always profile what you're doing, instead of doing premature optimization, in hope that you're smarter than the profiler.

Especially when it comes to using network, you may be very surprised. For example, you may believe that making more requests in parallel will be faster, but as Steve Gibson explains in episode 345 of Security Now, this is not always the case.

Legal aspects

Also note that screen scrapping is explicitly forbidden by the conditions of use (like on IMDB) on many websites. And if nothing is said on this subject in conditions of use, it doesn't mean that you can screen scrape those websites.

The fact that the information is available publicly on the internet doesn't give you the right to copy and reuse it this way neither.

Why? you may ask. For two reasons:

Most websites are relying on advertisement and marketing. When people use one of those websites directly, they waste some CPU/network bandwidth of the website, but in response, they may click on an ad or buy something sold on the website. When you screen scrape, your bot waste their CPU/network bandwidth, but will never click on an ad or buy something.

Displaying the information you screen scrapped on your website can have even worse effects. Example: in France, there are two major websites selling hardware. The first one is easy and fast to use, has a nice visual design, better SEO, and in general is very well done. The second one is a crap, but the prices are lower. If you screen scrape them and give the raw results (prices with links) to your users, they will obviously click on the lower price every time, which means that the website with pretty design will have less chances to sell the products.

People made an effort in collecting, processing and displaying some data. Sometimes they paid to get it. Why would they enjoy seeing you pulling this data conveniently and for free?


问:
What is best practice for log level in PHP?
When programming in C, I often get the advice to turn on many or all warnings and not ignore warnings.

Does the same hold in PHP, should I enable all warnings in the PHP log?

答:
In development phase of project I prefer to have: "E_ALL | E_STRICT" with display_errors turned on too so I can get all possible warning/erors/notices and so on. Just a simple lapsus in $user vs $usr can create a whole bunch of problems later and PHP without this setting will not create build problems but will generate broken bussiness logic.

In production mode it is best to have them turned on too but disabled display_errors flag. You can create your own custom error handler so logs can be written there or use for instance Apaches error log to find them (custom ones are better since you can write down more context that you need)


问:
What is enterprise software, exactly?
I don't understand the difference between "normal" software and enterprise software. Even after reading these...

"Enterprise Software" on Wikipedia

"Enterprise Software Is Sexy Again" on Techcrunch

"The Great Enterprise Software Swindle" on Coding Horror

I can't really wrap my head around the real differences. Is there any difference at all between the two? Why do people say enterprise software sucks?

答:
According to Martin Fowler's "patterns of enterprise application architecture", enterprise software usually involves access to persistent data. There's often a lot of data, with multiple users trying to access it concurrently. Enterprise applications usually need to integrate with other systems.

However, he also points out that there's a lot of variation in enterprise applications, and that not all or indeed any of the above points necessarily hold in all cases.

Title: What is enterprise software, exactly?


问:
RESTFul: state changing actions
I am planning to build a RESTfull API but there are some architectural questions that are creating some problems in my head. Adding backend business logic to clients is an option that I would like to avoid since updating multiple client platforms is hard to maintain in real time when business logic can rapidly change.

Lets say we have article as a resource ( api/article ), how should we implement actions like publish, unpublish, activate or deactivate and so on but to try to keep it as simple as possible?

1) Should we use api/article/{id}/{action} since a lot of backend logic can happen there like pushing to remote locations or change of multiple properties. Probably the hardest thing here is that we need to send all article data back to API for updating and multiuser work could not be implemented. For instance editor could send 5 seconds older data and overwrite fix that some other journalist just did 2 seconds ago and there is no way that I could explain to clients this since those publishing an article is really not in any way connected to updating the content.

2) Creating new resource can also be an option, api/article-{action}/id , but then returned resource would not be article-{action} but article which I am not sure if this is proper. Also in server side code article class is handling actuall work on both resource and I'm not sure if this goes against RESTfull thinking

Any suggestions are welcomed..

答:
If I understand you correctly, I think that what you have is a more of a 'business rule' determination issue than a technical issue.

The fact that an article can be overwritten could be resolved by introducing authorization levels where senior users can override junior user's versions.Also by introducing versions as well as a column to capture the state of the article  (e.g. 'in development', 'final', etc.), you could overcome this. You also may give the user the ability to select a given version either by a combination of time of submission and by the version number.

In all of the above cases, your service need to implement the business rules you set. So you could call the service with the parameters: userid, article, version, action (where the version is optional, again this depends on your business rules).

ContentLicense: CC BY-SA 4.0

Title: RESTFul: state changing actions


问:
Are developers expected to have skills of business analysts?
Our business analyst has left the team. We are now expected to do the work which was previously done by the business analyst, and the management thinks that a task which is done in three months by a business analyst can be done in one month by a developer.

My experience is in programming only, and I'm not familiar to the business intelligence tools. To me this seems like maybe an unfair comparison or expectation, and might even trivialize the role of a business analyst.

Has anyone else encountered this situation? How to deal with it?

答: In the positive side, if you get such an opportunity, you can utilize it well to improve yourself. It might be helpful to you when you get upgraded to a higher level. Obviously, it will be a great risk for the entire project since you can't concentrate on both of your positions, especially with a vague knowledge. Even though it's not your problem, if you really work hard, it would be easy for you to learn the tactics. However, if you find it really disgusting to do both at a time, then you have no other choice other than explaining your inability to your higher officials. Good Luck, then!!!</p>


答:
locally it is either stored as plain text or encrypted.

when encrypted the en/decryption key can be fixed per browser (hardcoded in the executable), per machine (generated at install and stored in the install directory) or per user (generated at first time use of password manager and stored in the %appdata%)

or they can be combined: the user level key is encrypted with the machine level key so that when malware takes the file where the passwords are stored it is stored it is useless without the user level and machine level keys

Some browsers also allow you to use a "master" password which which is combined with the existing key to provide more security

when you use a (good) synchronization service the passwords are never stored in plain text on the server and never decrypted server side.

Title: How does a web browser save passwords?


问:
What was the first programming language written for computers?
Looking at so many programming languages we have today, each one being unique in it's own way, I've tried to figure out what the first programming language written for computers is.

Looking at the release date for the popular ones I got somewhat close but I didn't look at less obvious ones, programming languages which are either dead or very little use nowadays. Fortran is the closest thing I got but I don't know if it's real.

In a nutshell: What was the first programming language written for computers? Are there any languages that derived from that language?

答:
I would argue that the first language created for a computer was the machine language of Babbage's analytical engine, the first Turing-complete general-purpose computer design.

Although Babbage's machine was never built, Ada Lovelace (actually Augusta Ada King (nee Byron), Countess of Lovelace) is widely credited as the worlds first programmer due to her implementation of an algorithm for generating the sequence of Bernoulli numbers on the analytical engine. What started out as a translation of Luigi Menabrea's article ended up a seminal work in computer science due to her copious notes, which ended up longer than the article she was translating.

In fact, the paper makes fascinating reading even today, I would highly recommend it.


答:
In short words, normal software would be the software made with individuals in mind, i.e. retail software or web applications targeting the general populace. Its success depends on how well it is received by users who in most part are offered a ready-made, 'standard issue' product. The development is an investment and the revenue comes from individual product or ad space sales.

On the other hand, enterprise software would be the software commissioned or developed internally by companies, either tailor-made from scratch or purchased from a third-party vendor and heavily customized for the company's business process.

The reason people say enterprise software sucks? I'd say there are three main reasons, heavily interconnected:

People who pay for it aren't the ones to use it - upper management / IT department makes the decisions. Ideally, they would consult the future users and make it imperative to adhere to what they have to say. The bad reputation comes from the cases where this is not so.

Systems like this are one-of-a-kind - retail software has to be well tested before putting it out on market, as the bugs may make it or break it in the view of its target users. Furthermore, it is used by dozens of people around the world on different machines, with different usage patterns, and so on, resulting in feedback useful for future releases. Enterprise software suffers from a small user base consisting mainly of people who have no choice but to use it regardless of user experience. As a result, less focus on user experience and less feedback to be gained from users (and often, no channel for such feedback when the work is being outsourced).

Companies who use the software are not software companies - they are using the software, it's critical for the business they are conducting, however it is secondary to their business objectives. As such, enterprise software will suffer from unreasonable deadlines, resources being under-allocated and being deemed 'good enough' while still being incomplete or under-tested.

Title: What is enterprise software, exactly?

Body:
I don't understand the difference between "normal" software and enterprise software. Even after reading these...

"Enterprise Software" on Wikipedia

"Enterprise Software Is Sexy Again" on Techcrunch

"The Great Enterprise Software Swindle" on Coding Horror

I can't really wrap my head around the real differences. Is there any difference at all between the two? Why do people say enterprise software sucks?


答:
formally I am not sure what its definition is. Some characteristics I think which are more important are

long term support (they want to know the company will be around and maintain the software)

usually solves enterprise business problems/processes (examples include HR, procurement ... i.e managing employees, paying them, procuring supplies)

customized/specific to the company's needs

Total cost, once you factor in all the licenses, consulting fees and any other expenses, rather than only the sticker price

Title: What is enterprise software, exactly?


问:
What is better for coding - desktop or laptop?
Use of desktops are decreasing day by day in daily life but for coding purpose are there any reasons for using desktop over laptop? </p>

答: I have a powerfull notebook, really good for software development and better: it's portable!

ContentLicense: CC BY-SA 2.5


问:
Better word for Optional Requirements?
What's a better word for an optional requirement in software engineering? The phrase is contradictory. I've used "Non-Core Requirements" in previous projects.</p>

答:
The term "out of scope requirement" can possibly be used. This means that the requirement has been captured within your process and is trackable, but it has been determined that the requirement is something that falls beyond the current scope of the system, due to a number of reasons, such as budget, schedule, time, or feasibility.

However, the phrase "optional requirement" is commonly used to denote something that is in scope, but not necessarily required by the system. It is a measure of the priority of the requirement. In my experiences, requirements are often prioritized as mandatory, desirable, or optional (although there are also other schemes). In order for a project to be considered complete and fully functional, all of the mandatory requirements must be satisfied. Given sufficient resources, desirable requirements would be implemented next. Finally, anything considered optional would be included.

I believe the confusion comes from the term "requirement". In the English language, a requirement is "a thing that is needed" or "a mandatory, compulsory, or necessary condition". However, in software engineering, the term requirement is simply a documented characteristic of a software system. The concept of optional and mandatory describe the priority of the documented characteristic of the software system.

Title: Better word for Optional Requirements?


答:
Requirements are categorized into 4 area in Software Engineering:

Business Requirements: Focuses on overall business goals and objectives of the system

User Requirements: Focuses on user's objectives and what users have to do to use the system to achieve business objectives

Functional Requirements: What functionality and tasks the system has to perform to achieve business objectives

Non-functional Requirements: What requirements are there other than functional ones. This includes environment, constraints, interface, maintenance issues, etc.

Now requirements can be Optional or Mandatory, depending upon the above 4 categories, I have outlined above. Optional requirements can also fall into the scope of the system under consideration or  out of it's scope as well. Optional requirements are good means to avoid Scope Creep and defining your scope in precise terms.

Optional Requirements will always be a part of Software Engineering as they help us identify the scope and are a good means to avoid Scope Creep. You can never say that they contradict the engineering  practices of SDLC. However, requirements have to prioritized and well defined.

Title: Better word for Optional Requirements?

Body: What's a better word for an optional requirement in software engineering? The phrase is contradictory. I've used "Non-Core Requirements" in previous projects.</p>


答:
Enterprise software is software that is targeted for businesses, nothing more, nothing less.

Just take Microsoft for example. They have a whole website dedicated to enterprise software, and what are some of their offerings? Well they are Windows 7, Windows 7 phone, IE9, MS Office, etc. Windows 7 has a few new built in features, but nothing you couldn't already due with an existing Windows 7 build that is targeted for consumers (after looking only briefly at their website) -- but the rest appear to be exactly the same as their consumer counterparts but.

It's just another buzz word...

Liz: Cross-promotional, deal mechanics, revenue streams, jargon, synergy.
Jack: That’s the best presentation I’ve ever seen.
-30 Rock, "Winter Madness"

Title: What is enterprise software, exactly?


答: We refer to them as "nice to have" features as opposed to requirements.</p>

Title: Better word for Optional Requirements?


答:
How about identifying it as an optional feature or optional tasks. These will only be done if at a certain point in the project it has been determined that there is time and money available to complete these features.

They could also be triggered if an external event occurs. If the customers makes the switch to Windows 8, the following tasks will need to be in done...

The description of the feature should include a deadline for determining if they will be done.

Title: Better word for Optional Requirements?


答:
One definition of enterprise software is the license. The software developer expects the purchaser to be installing the software on all of their machines. They may be paying for an unlimited license, or a maximum number of concurrent users.

The cost of the license of a max number of current users (lets say 100) is greater than the cost of 100 licenses, but it is also less then the cost of one license for each employee.

For web applications they will limit the number of admin account, but not limit the number of users in your domain.

I like enterprise software in some situations. In those cases the installation procedures have been streamlined to make it possible to install them from a server. Non-enterprise software would expect the user to install the software. Many companies lock down the machines, so that the average user can't install it. The enterprise software allows the software to be installed or updated automatically from a central repository.

Title: What is enterprise software, exactly?


问:
Too much to learn, dealing with overwhelming varieties of technologies
I am about to graduate, and I am already working as a web developer in our library IT department.

When I look at job postings I am absolutely overwhelmed by the sheer variety of technologies out there.

Some companies care about math + algorithms + data structures.  Some care about experiences in technology stack XYZ.  SQL, css, html, frameworks, javascript, design patterns etc.. etc... etc...

At some point I realized I just need to start at mastering a foundation to become employable at a better place and go from there.  But the skill-set to get me in the doors varies and I just don't have time to learn everything.

How do you deal with this issue?  What is the essential stack to become employable?  Say in php or ror arena.

Perhaps a smarter move would be to move to a technology stack with less variety like .net?

答:
The thing with job postings is that the requirements getting posted are often more extensive than the skill-set that is sufficient to get you the job, either because HR lists every buzzword they come up with, includes nice-to-have skills as required or wants to scare off incompetent candidates. People overestimate their abilities in cv's or outright lie about them, the same goes for job postings. If you feel you meet, say, 3/4 of the listed requirements, you can very well take your chances. If the HR is competent, they will seriously consider your application.

Also, getting an internship is by far the easiest way to get yourself in the door. You might want to look around for one.

Also, keep in mind that the climate on the job market isn't the same around the globe and it will show. Judging from Daniel Pittman's answer the situation in the US is very different to the one in Central Europe (which could be of interest to you looking at your nickname).


问:
Is programming a SubCulture?
I was going through this article:

http://en.wikipedia.org/wiki/Subculture

Which got mee thinking is programming a subculture?

After the a while I started thinking it really hard, and if you go really in depth this is a very complex and interesting question to ask.

YOu can even ask yourself if (heavy) internet (social) users are an subculture and programmers a culture within.

I think it might be an interesting discussion, hope you like it!

NOTE:

I linked the wiki article because it might be a good baseline, maybe you can base you answer  on Ken Gelder´s proposal to distinguish subcultures. But it should be based on a little bit more that intuition.

Thanks in advance!

Trufa

答:
Yes it can be. I've been involved in the demo scene in early 90s, building a diskmag called Imphobia talking about demos parties. The demo scene is defined like this:

The demoscene is a computer art subculture that specializes in producing demos, which are non-interactive audio-visual presentations that run in real-time on a computer. The main goal of a demo is to show off programming, artistic, and musical skills.

So yes I think programming is a subculture

Title: Is programming a SubCulture?


答:
Operations resulting in major state and behavior changes on the server side like the "publish" action you describe are difficult to model explicitly in REST. A solution I often see is to drive such complex behavior implicitly through data.

Consider ordering goods through a REST API exposed by an online merchant. Ordering is a complex operation. Several products will be packaged and shipped, your account will be charged, and you'll get a receipt. You can cancel your order for a limited amount of time and there is of course a full money back guarantee which allows you to send back products for a refund.

Instead of a complex purchase operation, such an API might allow you to create a new resource, a purchase order. At the beginning you can make any modifications you wish to it: add or remove products, change shipping address, choose another payment option, or cancel your order altogether. You can do all of these because you have not bought anything yet, you are just manipulating some data on the server.

Once your purchase order is complete and your grace period passes, the server locks your order to prevent any further changes. Only at this time the complex sequence of operations starts, but you cannot control it directly, only indirectly through the data you placed previously into the purchase order.

Based on your description, "publish" could be implemented in this fashion. Instead of exposing an operation, you place a copy of the draft you've reviewed and want to publish as a new resource under /publish. This guarantees the any subsequent updates to the draft won't be published even if the publish operation itself completes hours later.

Title: RESTFul: state changing actions

Body:
I am planning to build a RESTfull API but there are some architectural questions that are creating some problems in my head. Adding backend business logic to clients is an option that I would like to avoid since updating multiple client platforms is hard to maintain in real time when business logic can rapidly change.

Lets say we have article as a resource ( api/article ), how should we implement actions like publish, unpublish, activate or deactivate and so on but to try to keep it as simple as possible?

1) Should we use api/article/{id}/{action} since a lot of backend logic can happen there like pushing to remote locations or change of multiple properties. Probably the hardest thing here is that we need to send all article data back to API for updating and multiuser work could not be implemented. For instance editor could send 5 seconds older data and overwrite fix that some other journalist just did 2 seconds ago and there is no way that I could explain to clients this since those publishing an article is really not in any way connected to updating the content.

2) Creating new resource can also be an option, api/article-{action}/id , but then returned resource would not be article-{action} but article which I am not sure if this is proper. Also in server side code article class is handling actuall work on both resource and I'm not sure if this goes against RESTfull thinking

Any suggestions are welcomed..


答:
I would suggest you to take up a certification track if you like to focus as a developer. This would be the best way to prove your skill set and make yourself more marketable in the industry.

Also when you talk about stuff like Algorithms, Data Structures and Math then you do need to appreciate here that some employers require Computer Science graduates and some require IT professionals. You have to appreciate the difference between Computer Science and Information Technology. Identify a career path for yourself. Please check this answer here:

test for graduate software developer role?

Title: Too much to learn, dealing with overwhelming varieties of technologies

Body:
I am about to graduate, and I am already working as a web developer in our library IT department.

When I look at job postings I am absolutely overwhelmed by the sheer variety of technologies out there.

Some companies care about math + algorithms + data structures.  Some care about experiences in technology stack XYZ.  SQL, css, html, frameworks, javascript, design patterns etc.. etc... etc...

At some point I realized I just need to start at mastering a foundation to become employable at a better place and go from there.  But the skill-set to get me in the doors varies and I just don't have time to learn everything.

How do you deal with this issue?  What is the essential stack to become employable?  Say in php or ror arena.

Perhaps a smarter move would be to move to a technology stack with less variety like .net?


答:
Knuth, The Early Development of Programming Languages, originally published in Encyclopedia of Computer Science and Technology (1977) and reprinted in Selected Papers on Computer Languages gives information on early languages (including the implementation a small program) and is probably the best accessible source on them.

The earlier he cites is Plankalkül (Zuse, 1945), which wasn't implemented and the describing paper not even published before 1972) thus had little influence.

Then he gives Flow Diagrams (Goldstine and von Neumann, 1946), Composition (Curry, 1948), Short Code (Mauchly et al., 1949), Intermediate PL (Burks, 1950) and some later one.

Sammet, Programming Languages: History and Fundamentals is little concerned by "early languages", but gives a list of about 150 languages from before 1959.

FORTRAN is probably the earliest one still existing and having lot of influence.  COBOL, LISP are also still existing and -- for LISP -- a lot of variants and descendants. ALGOL is probably the major influencing programming languages which hasn't evolved in direct line until now -- but it has lot of presence, C being one of its indirect descendant.

Body:
Looking at so many programming languages we have today, each one being unique in it's own way, I've tried to figure out what the first programming language written for computers is.

Looking at the release date for the popular ones I got somewhat close but I didn't look at less obvious ones, programming languages which are either dead or very little use nowadays. Fortran is the closest thing I got but I don't know if it's real.

In a nutshell: What was the first programming language written for computers? Are there any languages that derived from that language?


答:
we need to send all article data back to API for updating and multiuser work could not be implemented. For instance editor could send 5 seconds older data and overwrite fix that some other journalist just did 2 seconds ago and there is no way that I could explain to clients this since those publishing an article is really not in any way connected to updating the content.

This sort of thing is a challenge no matter what you do,  It's a very similar problem to distributed source control (mercurial, git, etc.), and the solution, spelled in HTTP/ReST, looks a bit similar.

Supposing you've got two users, Alice and Bob, both working on /articles/lunch.  (for clarity, response is in bold face)

First, alice creates the article.

```<code>PUT /articles/lunch HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?

<strong>301 Moved Permanently
Location: /articles/lunch/1 </strong></code>```

The server did not create a resource, because there was no "version" attached to the request, (assuming an identifier of /articles/{id}/{version}.  To perform the creation, Alice was redirected to the url of the article/version she'll be creating.  Alice's user agent will then reapply the request at the new address.

```<code>PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?

<strong>201 Created
</strong></code>```

And now the article has been created.  next, bob looks at the article:

```<code>GET /articles/lunch HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk

<strong>301 Moved Permanently
Location: /articles/lunch/1 </strong></code>```

Bob looks there:

```<code>GET /articles/lunch/1 HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk

<strong>200 Ok
Content-Type: text/plain

Hey Bob, what do you want for lunch today?</strong></code>```

He decides to add his own change.

```<code>PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk

Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?

<strong>301 Moved Permanently
Location: /articles/lunch/2</strong></code>```

As with Alice, Bob is redirected to where he will be creating a new version.

```<code>PUT /articles/lunch/2 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk

Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?

<strong>201 Created</strong></code>```

Finally, Alice decides that she would like to add to her own article:

```<code>PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?
I was thinking about getting Sushi.

<strong>409 Conflict
Location: /articles/lunch/3
Content-Type: text/diff

---/articles/lunch/2
+++/articles/lunch/3
@@ 1,2 1,2 @@
 Hey Bob, what do you want for lunch today?
-Does pizza sound good to you, Alice?
+I was thinking about getting Sushi.

</strong></code>```

Instead of being redirected as normal, a different status code is returned to the client, 409, which tells Alice that the version she was trying to branch from has already been branched.  The new resources was created anyways (as shown by the Location header), and the differences between the two was included in the response body.  Alice now knows that the request she just made needs to be merged some how.

All of this redirection is related to the semantics of PUT, which requires that new resources be created exactly where the request line asks.  this could also save a request cycle using POST instead, but then the version number would have to be encoded in the request by some other magic, which seemed less obvious to me for the purposes of illustration, but would probably still be preferred in a real API to minimize request/response cycles.

Title: RESTFul: state changing actions

Body:
we need to send all article data back to API for updating and multiuser work could not be implemented. For instance editor could send 5 seconds older data and overwrite fix that some other journalist just did 2 seconds ago and there is no way that I could explain to clients this since those publishing an article is really not in any way connected to updating the content.

This sort of thing is a challenge no matter what you do,  It's a very similar problem to distributed source control (mercurial, git, etc.), and the solution, spelled in HTTP/ReST, looks a bit similar.

Supposing you've got two users, Alice and Bob, both working on /articles/lunch.  (for clarity, response is in bold face)

First, alice creates the article.

PUT /articles/lunch HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?

301 Moved Permanently
Location: /articles/lunch/1

The server did not create a resource, because there was no "version" attached to the request, (assuming an identifier of /articles/{id}/{version}.  To perform the creation, Alice was redirected to the url of the article/version she'll be creating.  Alice's user agent will then reapply the request at the new address.

PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?

201 Created

And now the article has been created.  next, bob looks at the article:

GET /articles/lunch HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk

301 Moved Permanently
Location: /articles/lunch/1

Bob looks there:

GET /articles/lunch/1 HTTP/1.1
Host: example.com
Authorization: Basic Ym9iOnBhc3N3b3Jk

200 Ok
Content-Type: text/plain

Hey Bob, what do you want for lunch today?

He decides to add his own change.

PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk

Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?

301 Moved Permanently
Location: /articles/lunch/2

As with Alice, Bob is redirected to where he will be creating a new version.

PUT /articles/lunch/2 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic Ym9iOnBhc3N3b3Jk

Hey Bob, what do you want for lunch today?
Does pizza sound good to you, Alice?

201 Created

Finally, Alice decides that she would like to add to her own article:

PUT /articles/lunch/1 HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Basic YWxpY2U6c2VjcmV0

Hey Bob, what do you want for lunch today?
I was thinking about getting Sushi.

409 Conflict
Location: /articles/lunch/3
Content-Type: text/diff

---/articles/lunch/2
+++/articles/lunch/3
@@ 1,2 1,2 @@
 Hey Bob, what do you want for lunch today?
-Does pizza sound good to you, Alice?
+I was thinking about getting Sushi.

Instead of being redirected as normal, a different status code is returned to the client, 409, which tells Alice that the version she was trying to branch from has already been branched.  The new resources was created anyways (as shown by the Location header), and the differences between the two was included in the response body.  Alice now knows that the request she just made needs to be merged some how.

All of this redirection is related to the semantics of PUT, which requires that new resources be created exactly where the request line asks.  this could also save a request cycle using POST instead, but then the version number would have to be encoded in the request by some other magic, which seemed less obvious to me for the purposes of illustration, but would probably still be preferred in a real API to minimize request/response cycles.


问:
Should cookies be used in a RESTful API?
I'm specifically interested in how users perform authorized / authenticated operations on a web API.

Are authentication cookies compatible with the REST philosophy, and why?

答:
An ideal ReSTful service allows clients (which may not be in-browser) to perform any needed task in one request; because the full state needed to do that is held by the client, not the server.  Since the client has full control of the state, it can create the state on its own (if that is legitimate), and only talk to the API to "get 'er done".

Requiring cookies can make that difficult.  For clients besides browsers, managing cookies is a pretty big inconvenience compared to query params, plain request headers or the request body.  On the other hand, In browser, using cookies can make lots of things much simpler.

So an API might first look in the Authorization header for the authentication data it needs, since that's probably the place where non-browser clients will prefer to put it, but to simplify and streamline browser-based clients, it might also check for a session cookie for server side log in, but only if the regular Authorization header was missing.

Another example might be a complex request that normally requires lots of parameters set.  A non interactive client would have no trouble jamming all of that data into one request, but a HTML form based interface might prefer to break the request into several pages (something like a set of 'wizard' pages) so that users aren't presented with options that are not applicable based on previous selections.  All of the intermediate pages could store the values in client side cookies, so that only the very last page, where the user actually submits the request, has any server side effect at all.  The API could look for the needed attributes in the request body, and fall back to looking at cookies if the needed parameters weren't there.

Edit: in RE to @Konrad's comment below:

Tokens in comparison are harder to implement especially because you can't easily invalidate the token without storing them somewhere.

er... you are validating the cookies on the server side, right?  Just because you told the browser to discard a cookie after 24 hours doesn't mean it will.  That cookie could be saved by a highly technical user and reused long after it has "expired".

If you don't want to store session data on the server side, you should store it in the token (cookie or otherwise).  A self contained auth token is sometimes called a Macaroon.  How this is passed between client and server (whether by cookie, as extra headers, or in the request entity itself) is totally independent of the authentication mechanism itself.


问:
Why to let / not let developers test their own work
I want to gather some arguments as to why letting a developer testing his/her own work as the last step before the product goes into production is a bad idea, because unfortunately, my place of work sometimes does this (the last time this came up, the argument boiled down to most people being too busy with other things and not having the time to get another person familiar with that part of the program - it's very specialised software).

There are test plans in this case (though not always), but I am very much in favor of making a person who didn't make the changes that are tested actually doing the final testing. So I am asking if you could provide me with a good and solid list of arguments I can bring up the next time this is discussed. Or to provide counter-arguments, in case you think this is perfectly fine especially when there are formal test cases to test.

答:
Eeveryone should test - Develpers test code, QA'ers test functionality, Marketing test messaging.  That way everyone shares the same philosophies and language around testing which is half the battle.

Testing is routine maintenance and I usually use analogies to compare.  For instance the car oil change analogy.  You never 'have to' change your oil.  But you do it regularly anyway.  Same for brushing your teeth.  There's a reason you maintain them daily - they're not going to break 'today', it's all about tomorrow and future days and making an investment.

Everyone should share in the responsibility to test.  A QA team is important, however making "testing" as something that only the QA team does makes it to be a 'separate' activity that it not integrated to product development and workflow which is not a good thing.

When anything ever breaks in production do two things:

Say "hmm, do we have a test for that" as the first comment.

Make any fix include tests for the issue, first to reproduce, than fix.


答:
In the Volere template the term "Waiting room" is used.

...This template is intended for use as the foundation for your requirements specifications. The template provides for each of the requirements types appropriate for today's business, scientific and software systems. It provides a checklist, structure and traceability for your requirements... The template is tool independent, and has been successfully used with Yonix, Requisite, DOORS, Caliber RM, IRqA and other popular tools...

The Volere techniques are described in the book Mastering the Requirements Process by Suzanne Robertson and James Robertson...

Title: Better word for Optional Requirements?


答:
I agree with gnat's comment, too, but I have also seen a lot of situations where splitting the roles between analyst (with no programming tasks) and developers (who are not allowed to talk to the customer directly) lead to "Chinese whisper". To my experience, you can often save a lot of effort and misunderstanding if your analyst is a senior programmer who does some essential parts of the programming by himself, and talks to the rest of the team not just in plain English, but also by utilizing the programming languages of the team.

So the expectation of your management that you might save some time and effort with no BA might not be completely wrong.

Title: Are developers expected to have skills of business analysts?

Body:
Our business analyst has left the team. We are now expected to do the work which was previously done by the business analyst, and the management thinks that a task which is done in three months by a business analyst can be done in one month by a developer.

My experience is in programming only, and I'm not familiar to the business intelligence tools. To me this seems like maybe an unfair comparison or expectation, and might even trivialize the role of a business analyst.

Has anyone else encountered this situation? How to deal with it?


答: A better word for an optional requirement is "Recommendation"

Title: Better word for Optional Requirements?


答:
One of the hard parts of working in the software development industry is that, generally speaking, you can expect to face some portion of this problem for the rest of your career.  The industry is changing fast enough that if you sit still you find yourself more and more left behind.  (Consider where, eg, Windows 3.1 programming skills would help you out in todays job market, for example.)

As a new graduate, many employers are realistic, and understand that you don't have a long history of industry skills to draw on.  Certainly, over the last ten years of hiring at a range of companies, and in talking to peers who are part of the hiring process elsewhere, this is true both in the US, and in Australia, and Europe.

The standard things you can bring to the table as a new graduate are:

enthusiasm for the company, the industry, the problem space, and the job itself.

a passion for learning, and proof that you are able to learn on the fly.

proof that you have actually mastered the basic skills of the course you took.

Those are more or less the "pass/fail" level: there are enough graduates who are enthusiastic about the job, and who have a demonstrable passion for learning, that if you come across as "just after a job" you are less likely to sell yourself well.

Beyond that, the things that make a candidate most compelling when we hire at the intern or new graduate level are both reasonably easy and reasonable hard in their own ways:

We look for someone who demonstrated both passion and success outside the requirements of the course - good past internships, competition wins, industry membership, a blog that documents their learning and experiments, participation in the open source community, a visible and competent presence on the StackExchange family, and so on.

We also look for someone who can do the job - and nothing convinces like doing it.  My current employer has an open source project, so contributing to that is a big help getting a job - since that exactly maps to a part of the job we care about.

For closed companies, demonstrating that you can write code, and well, is good though.  We would absolutely favour candidates who had code available publicly that we could read through and understand their general competence.

The two main paths to that are to contribute to an existing open project, or to start your own - even if it isn't wildly successful - in visible places like GitHub, or other online code repositories, or in visible open source projects.

Finally, remember two depressing things:

One, most employers are going to look for your online presence.  You should check that reflects what you do want them to know, like your technical skills, and that it doesn't reflect things you don't want to emphasise, like the story of the day you skipped an exam because your hangover was too big.  (Which, sad but true, a tiny proportion of our rejected candidates get kicked out on.)

Two, your are going to graduate in a terrible job market for people without industry experience.  Right now there are lots of people who have one, two, five, even ten years experience who can't find a job.

Especially in the US that means they are hungry for full time anything (with benefits) and are willing to consider anything - even internships - in order to be able to work.

So, right now you will get lots of rejections.  Don't be mistaken - you could be amazing, and you would still get lots of rejections.  The competition is incredible, so don't be discouraged.  Keep plugging away with honesty, and work on improving your skills by learning bits and pieces of those things the job adverts list.


答:
It's not overwhelming,

math, your a graduate, you can do maths

algorithms, comp-sci grads know algorithms

data structures, comp-sci grads know data structures

technology stack XYZ, learn one stack the rest are similar enough

SQL, it's the database, if you build any app you'll deal with the database

css, it's the visual part of web dev, if you build any web app you'll know CSS

html, it's the content of the website, you know this if you build websites

frameworks, you will use one if your building a web app

javascript, you will learn this if your building a web app

design patterns, you implement these if you code

If you have a comp-sci degree and you've build a web application then you meet all these criteria.


答:
For software requirements documentation, wording Optional Requirements is perfectly OK, as long as you use this term in conformance with RFC 2119 Key words to Indicate Requirement Levels - ie to indicate items that are truly optional.

When your specification text implies verb instead of adjective, use "MAY" instead of "OPTIONAL".

Since it is small and easy to read, RFC text is fully quoted below:

```
    Network Working Group                                         S. Bradner
    Request for Comments: 2119                            Harvard University
    BCP: 14                                                       March 1997
    Category: Best Current Practice

            Key words for use in RFCs to Indicate Requirement Levels

    Status of this Memo

       This document specifies an Internet Best Current Practices for the
       Internet Community, and requests discussion and suggestions for
       improvements.  Distribution of this memo is unlimited.

    Abstract

       In many standards track documents several words are used to signify
       the requirements in the specification.  These words are often
       capitalized.  This document defines these words as they should be
       interpreted in IETF documents.  Authors who follow these guidelines
       should incorporate this phrase near the beginning of their document:

          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
          "OPTIONAL" in this document are to be interpreted as described in
          RFC 2119.

       Note that the force of these words is modified by the requirement
       level of the document in which they are used.

    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
       definition is an absolute prohibition of the specification.

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

    4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
       there may exist valid reasons in particular circumstances when the
       particular behavior is acceptable or even useful, but the full
       implications should be understood and the case carefully weighed
       before implementing any behavior described with this label.

    5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item because a
       particular marketplace requires it or because the vendor feels that
       it enhances the product while another vendor may omit the same item.
       An implementation which does not include a particular option MUST be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In the
       same vein an implementation which does include a particular option
       MUST be prepared to interoperate with another implementation which
       does not include the option (except, of course, for the feature the
       option provides.)

    6. Guidance in the use of these Imperatives

       Imperatives of the type defined in this memo must be used with care
       and sparingly.  In particular, they MUST only be used where it is
       actually required for interoperation or to limit behavior which has
       potential for causing harm (e.g., limiting retransmissions)  For
       example, they must not be used to try to impose a particular method
       on implementors where the method is not required for interoperability.

    7. Security Considerations

       These terms are frequently used to specify behavior with security
       implications.  The effects on security of not implementing a MUST or
       SHOULD, or doing something the specification says MUST NOT or SHOULD
       NOT be done may be very subtle. Document authors should take the time
       to elaborate the security implications of not following
       recommendations or requirements as most implementors will not have
       had the benefit of the experience and discussion that produced the
       specification.

    8. Acknowledgments

       The definitions of these terms are an amalgam of definitions taken
       from a number of RFCs.  In addition, suggestions have been
       incorporated from a number of people including Robert Ullmann, Thomas
       Narten, Neal McBurnett, and Robert Elz.

```

It wouldn't hurt if your documentation refers to RFC as the source of definitions:

This document uses definitions based upon those specified in RFC 2119.

Title: Better word for Optional Requirements?

Body:
For software requirements documentation, wording Optional Requirements is perfectly OK, as long as you use this term in conformance with RFC 2119 Key words to Indicate Requirement Levels - ie to indicate items that are truly optional.

When your specification text implies verb instead of adjective, use "MAY" instead of "OPTIONAL".

Since it is small and easy to read, RFC text is fully quoted below:

    Network Working Group                                         S. Bradner
    Request for Comments: 2119                            Harvard University
    BCP: 14                                                       March 1997
    Category: Best Current Practice

            Key words for use in RFCs to Indicate Requirement Levels

    Status of this Memo

       This document specifies an Internet Best Current Practices for the
       Internet Community, and requests discussion and suggestions for
       improvements.  Distribution of this memo is unlimited.

    Abstract

       In many standards track documents several words are used to signify
       the requirements in the specification.  These words are often
       capitalized.  This document defines these words as they should be
       interpreted in IETF documents.  Authors who follow these guidelines
       should incorporate this phrase near the beginning of their document:

          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
          "OPTIONAL" in this document are to be interpreted as described in
          RFC 2119.

       Note that the force of these words is modified by the requirement
       level of the document in which they are used.

    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
       definition is an absolute prohibition of the specification.

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

    4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
       there may exist valid reasons in particular circumstances when the
       particular behavior is acceptable or even useful, but the full
       implications should be understood and the case carefully weighed
       before implementing any behavior described with this label.

    5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item because a
       particular marketplace requires it or because the vendor feels that
       it enhances the product while another vendor may omit the same item.
       An implementation which does not include a particular option MUST be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In the
       same vein an implementation which does include a particular option
       MUST be prepared to interoperate with another implementation which
       does not include the option (except, of course, for the feature the
       option provides.)

    6. Guidance in the use of these Imperatives

       Imperatives of the type defined in this memo must be used with care
       and sparingly.  In particular, they MUST only be used where it is
       actually required for interoperation or to limit behavior which has
       potential for causing harm (e.g., limiting retransmissions)  For
       example, they must not be used to try to impose a particular method
       on implementors where the method is not required for interoperability.

    7. Security Considerations

       These terms are frequently used to specify behavior with security
       implications.  The effects on security of not implementing a MUST or
       SHOULD, or doing something the specification says MUST NOT or SHOULD
       NOT be done may be very subtle. Document authors should take the time
       to elaborate the security implications of not following
       recommendations or requirements as most implementors will not have
       had the benefit of the experience and discussion that produced the
       specification.

    8. Acknowledgments

       The definitions of these terms are an amalgam of definitions taken
       from a number of RFCs.  In addition, suggestions have been
       incorporated from a number of people including Robert Ullmann, Thomas
       Narten, Neal McBurnett, and Robert Elz.

It wouldn't hurt if your documentation refers to RFC as the source of definitions:

This document uses definitions based upon those specified in RFC 2119.


答: In my business (spacecraft), they are called either "goals", indicating that they are documented and effort will be expended to meet them, but the system will still be considered successful if they are not met; "desirements" (not a real word, but there you are), indicating that someone wants them and they are trying to attain the status of goals but aren't accepted or documented yet; or "creeping requirements" which is a more derogatory version of desirements indicating things that are trying to take up resources but that aren't worth it in a project trying to achieve "good enough" where they will compromise or threaten achieving the real requirements.</p>

Title: Better word for Optional Requirements?


答:
I appreciate it's not an answer to your question, but in my world, it's still a requirement, even if for whatever reason you're not going to fulfil it.

I like the MoSCoW approach (Must Have, Should have, Could have, Won't have this time) to categorising requirements with users, along with other factors (in my regulated world, requirements can be critical or non-critical, and many an argument flares up over optional but critical requirements.)

Title: Better word for Optional Requirements?


问:
Secure Open Source?
I want to make a delicate application of mine (an antivirus actually) open source but I want to have a control on who really obtains the source or not. Preferably they should apply and I or administrators approve their applications. Is there any online platform for this?

The main reason for the control/security is to possibly prevent malware makers to easily discover how to bypass the stealth checking methods it utilizes for malware detection.

Edit: I am looking for advice - possibly to hear from someone who has done something similar.

Thanks!

答:
One of the main definitions of open source software is that anyone who receives the source code can freely distribute it.  </p>

<p>Perhaps you should look into a proprietary license.  There is nothing wrong with not releasing code as open source, and it certainly seems like a proprietary license would fit your needs much better.  Even if you license a product as proprietary, you can release the source code to parties that you want, but you can still have control on what they do with that code through agreements you make with them before you release it.    </p>

Title: Secure Open Source?

Body:
One of the main definitions of open source software is that anyone who receives the source code can freely distribute it.

Perhaps you should look into a proprietary license.  There is nothing wrong with not releasing code as open source, and it certainly seems like a proprietary license would fit your needs much better.  Even if you license a product as proprietary, you can release the source code to parties that you want, but you can still have control on what they do with that code through agreements you make with them before you release it.


答:
One reason for dislike of enterprise is that in many cases it is designed to be a one size fits all. Like with clothes, what this really means is one size fits no-one.

You see large amounts of configuration sometimes extreme amounts (Siebel, SAP, etc. all work on this premise).  So much so that large teams of "developers" are needed to program the already mega expensive software to work.

In some cases this makes sense in others not so much so.  It makes sense when a company has decided to either align processes with the software or the software already aligns with their process.

When the sales person starts telling you it "can" be made to do that or some feature is "supported" run for the hills

Disclaimer: Veteran of 3 failed Siebel attempts at the same company.

Title: What is enterprise software, exactly?


答:
Enterprise software is just that, software aimed at enterprises.  It is usually unstated that this means medium to large scale enterprises (companies).

Some key features that come to mind are:

frequently distribution is through institutional licenses.

usage if often paid by 'bands' of user size than a fixed  cost per user per license.

upgrades are often done through system-wide pushes rather than ad-hoc user by user.

Frequently used for desktop components.

higher use and integration with existing internal authentication/authorization methods.

Title: What is enterprise software, exactly?


问:
Is it better to learn the DOM or jQuery first?
I have gotten very familiar with the core functionality of Javascript and now I am aiming at learning DOM manipulation. I have already thought of learning jQeury for this but I don't know if it is good idea to learning it before first getting familiar with the core functionality of the DOM.

Should I first learn the core functionality of the DOM and then learn jQuery? If so, why? Or should I just go on ahead and learn jQuery?

答:
It depends.

Do you want to support IE6-8 ?

Do you have time/desire to learn browser quirks?

If you don't have the time/desire to learn how to fix IE6-8 by hand then using jQuery is not a bad option, note that jQuery is a mediocre solution for cross browser compliant code but it's a quick and dirty solution.

If you don't care about oldIE and have the time to learn the DOM then start reading about the DOM

In an ideal situation you don't need jQuery, your better off using the real DOM API and using polyfills for browser compliance.

Knowing and using the real DOM API increases readability/maintainability because all web developers know the DOM and only some know library X. It also significantly increases performance because abstractions like jQuery are an order of magnitude slower.


答:
Learn the DOM. By doing that, you will have a better understanding and appreciation for what libraries like jQuery do for you. This also means you'll be better suited in the long run if you must change tools. The DOM will always be there, and is common ground for understanding the fundamental design choices for any given library that interacts with the DOM.

With all that given, I don't think there is anything wrong with learning the DOM alongside jQuery. Especially if you have a project that requires JQuery and needs to get done relatively soon. I think the important thing is that you learn how the DOM works in order to keep yourself decoupled from any particular library.

Title: Is it better to learn the DOM or jQuery first?

Body:
I have gotten very familiar with the core functionality of Javascript and now I am aiming at learning DOM manipulation. I have already thought of learning jQeury for this but I don't know if it is good idea to learning it before first getting familiar with the core functionality of the DOM.

Should I first learn the core functionality of the DOM and then learn jQuery? If so, why? Or should I just go on ahead and learn jQuery?


问:
Visually and audibly unambiguous subset of the Latin alphabet?
Imagine you give someone a card with the code "5SBDO0" on it.

In some fonts, the letter "S" is difficult to visually distinguish from the number five, (as with number zero and letter "O").

Reading the code out loud, it might be difficult to distinguish "B" from "D", necessitating saying "B as in boy," "D as in dog," or using a "phonetic alphabet" instead.

What's the biggest subset of letters and numbers that will, in most cases, both look unambiguous visually and sound unambiguous when read aloud?

Background:

We want to generate a short string that can encode as many values as possible while still being easy to communicate.

Imagine you have a 6-character string, "123456".  In base 10 this can encode 10^6 values.

In hex "1B23DF" you can encode 16^6 values in the same number of characters, but this can sound ambiguous when read aloud. ("B" vs. "D")

Likewise for any string of N characters, you get (size of alphabet)^N values.

The string is limited to a length of about six characters, due to wanting to fit easily within the capacity of human working memory capacity.

Thus to find the max number of values we can encode, we need to find that largest unambiguous set of letters/numbers.  There's no reason we can't consider the letters G-Z, and some common punctuation, but I don't want to have to go manually pairwise compare "does G sound like A?", "does G sound like B?", "does G sound like C" myself.  As we know this would be O(n^2) linguistic work to do =)...

答:
You should partition the set of alphanumerics into groups by visual similarity, and choose a “most iconic” representative from each group. This is somewhat subjective, though you could run user tests on it. The choices you make also depend on whether the figures will be printed or handwritten. For example:

{ O, 0, Q, D }

{ I, L, 1 }

{ B, 8 }

{ Z, 2 }

{ S, 5 }

{ 7, T }

{ U, V, Y }

Similarly, partition characters by the phonetic similarity of their names’ pronunciations:

{ A [ʔeɪ], 8 [ʔeɪ(ʔ/t)] }

= starts with [ʔeɪ]

{ P [pi:], B [bi:], V [vi:], D [di:], T [ti:], E [ʔi:] }

= stop/fricative + [i:]

{ G [ʤi:], C [si:], Z [zi:], 3 [θɹi:] }

= fricative/affricate (cluster) + [i:]

{ M [ɛm], N [ɛn] }

= [ɛ] + nasal

{ S [ɛs], F [ɛf], X [ɛks] }

= [ɛ] + fricative/affricate

{ I [ʔaɪ], Y [waɪ], 5 [faɪv], 9 [naɪn] }

= consonant + [aɪ] + (consonant)

{ Q [kjʉ:], U [jʉ:], 2 [t(j)ʉ:] }

= consonant + [(j)ʉ:]

These are, of course, not the only possible partitions, just what come to mind at the moment. Regardless, they should be enough to get you started for further testing. Also, these aren’t backed up by any professional sources—I cite only my hobbyist backgrounds in typography and phonetics.


问:
Need some critique on .NET/WCF SOA architecture plan
I am working on a refactoring of some services and would appreciate some critique on my general approach. I am working with three back-end data systems and need to expose an authenticated front-end API over http binding, JSON, and REST for internal apps as well as 3rd party integration. I've got a rough idea below that's a hybrid of what I have and where I intend to wind up.

I intend to build guidance extensions to support this architecture so that devs can build this out quickly.

Here's the current idea for our structure:

Front-end WCF routing service (spread across multiple IIS servers via hardware load balancer)

Load balancing of services behind routing is handled within routing service, probably round-robin

One of the services will be a token

Multiple bindings per-service exposed to address JSON, REST, and whatever else comes up later

All in/out is handled via POCO DTOs

Use unity to scan for what services are available and expose them

The front-end services behind the routing service do nothing more than expose the API and do conversion of DTO<->Entity

Unity inject service implementation to allow mocking

automapper for DTO/Entity conversion

Invoke WF services where response required immediately

Queue to ESB for async WF -- ESB will invoke WF later

Business logic WF layer

Expose same api as front-end services

Implement business logic

Wrap transaction context where needed

Call out to composite/atomic services

Composite/Atomic Services

Exposed as WCF

One service per back-end system

Standard atomic CRUD operations plus composite operations

Supports transaction context

The questions I have are:

Are the separation of concerns outlined above beneficial?  Current thought is each layer below is its own project, except the backend stuff, where each system gets one project. The project has a servicehost and all the services are under a services folder. Interfaces live in a separate project at each layer. DTO and Entities are in two separate projects under a shared folder.

I am currently planning to build dedicated services for shared functionality such as logging and overload things like tracelistener to call those services. Is this a valid approach?

Any other suggestions/comments?

答:
It sounds quite a bit complicated, conversion of DTOs to Entities (entity framework objects, I trust) which also sounds like quite a bottleneck and 4 distinct layers...

I mean you have n services directly exposed to the client via a load balancer, but these then call a service that performs DTO conversion, that then calls a WF (windows workflow?) service - is this latter duplicated across each server you're load balancing, or is it a single service that is called? This then calls out to the back-end wrapper services.

Now, it's good you have the back-end wrappers to encapsulate the 3 data services, and good you have the JSON/REST client API. I think the problem comes in the middle - why not combine these 2 layers together, ignore the EF conversion and stick to directly manipulating the DTOs. It'll be faster (especially as you're probably going to have to convert back to DTOs to send to the 3 data services anyway), and easier to understand. Sure, you don;t get to use the 'cool EF tech', but tech for tech's sake is never a good idea.

Personally, I'd even try to merge the WCF wrappers with the middle tier too, unless there's an absolute need to make all 3 services look alike, you might as well call them using their native systems, perhaps using a local, in-proc library to wrap them.

Remember, ultimately, keeping it simple will pay dividends in the future. Your current system will be difficult to refactor with new back-end systems as a small amount of dev will have to touch a lot of different layers and technologies.


答:
jQuery depends on you knowing the DOM because that is what you are manipulating.

"There's not much point to jQuery without the DOM"

the DOM is just HTML and has no such dependency on jQuery.

"You can do plenty of static site work with just the DOM"

Of course there's edge cases and exceptions but for general learning purposes I would go by the above.


答:
To oversimplify, Enterprise software is software aimed for the business.

For better or worse, this type of software comes with some painful trends:

More sign-offs implies fewer trade-offs.

Lots of focus on interfaces.

Formal planning processes.

Less willingness to just try things.

Frequently unrelated to how the company makes money.  (Internal HR, etc)

Doesn't always attract top talent.

Frequently late and over budget.

The extreme example is a large PeopleSoft implementation with 100 consultants attached to it that gets implemented 2 years late.

People don't like working for large programs designed by committee.

It doesn't have to be this way, but it frequently is.

Title: What is enterprise software, exactly?