答:
This isn't the sort of question suited for SO, but with that said, I'll throw you some quick points before it gets closed or migrated.

Firstly, you would need to consult a lawyer. There is no substitute for speaking with someone who can provide you with correct advice rather than the random mumblings of most people online.

Anyway... Employment Law is pretty complex, especially when it comes to Intellectual Property Rights.

For example, if you are employed by a Manufacturing company to create some Wonder Design, then discover the perfect design in your own time, your employer will generally (without an agreement pointing otherwise) be the owner of any Copyright in the works which you produce.

Also, you would need to determined if you are actually employed by this person who you have done work for. Just because you call him your employer, does not mean that he is in fact your employer. In fact, even because he pays you in renumeration for work you have completed, does not mean he is your employer. This is all pretty complex stuff too and it all boils down to contracts, the length of the work you completed, how you received your money, your tax obligations, etc.

Additionally, the fact that you have included this preexisting code into this project does not mean that you relinquish any Copyright in your work.

You are still the owner of the Copyright in your works, however, you will have most likely granted an implied licence to use your work since you have included it in this project.
This of course, is making the assumption, that the work you carried out, has assigned all Intellectual Property Rights in this person who hired you.

It might actually be the case that you were paid for work, but you retain full IPR and you have just granted a licence to use the software which you have developed.

If I was to offer my non legal opinion based on what you have provided so far,
I would say that this person is your employer, and that the Intellectual Property Rights in the work you have created thus far is held by your employer.
You have Copyright in the work which you yourself have created, however, you will have granted an irrevocable implied licence to your employer to use your work, and additionally any chance which you now make on this project will belong to your employer.

Also remember, you can have Copyright in even infringing works of Copyright. And just because you have Copyright in something, doesn't always mean that it is enforceable.

I would recommend that you:

Dig up your contracts

Create an agreement with your employee that recognises that you are grantee free use of your own code for this project, however, it should also be noted that any work that you do in your own time is your own work.


问:
Should ActiveRecord-based domain models have visible properties? Why or why not?
Should ActiveRecord-based domain models have visible properties? Why or why not?

My experience and studies have always lead me to believe that object properties should always be protected, and that data should only be manipulated/accessed through methods. This ensures that if the internals of the class need to be refactored, other objects that rely on that object do not then also need to be refactored.

I often see domain models with publicly visible properties however, and the models can be passed to say view objects which directly access those properties while building the view. I have always thought that this is perhaps the one exception to the above mentioned rule, because otherwise you would basically have to create getters and setters for objects like the view to use, or some other equally troubling sounding solution. Perhaps I am wrong on this? I would like to get some feedback on the subject.

答:
Public methods are extremely convenient and require less code, as you don't have to write the mutator methods. I'm guessing that reason Active Record models with public properties are common is that they are considered PODs (POJOs, POPOs, POCOS etc), DTOs or Value Objects.

But models typically carry behaviour and there's absolutely no reason, conceptual or otherwise, for any other class that carries behaviour to go against encapsulation. Unless you have very extreme performance considerations and want to keep everything as lightweight as possible I'd advice against exposing your properties.

My experience and studies have always lead me to believe that object properties should always be protected, and that data should only be manipulated/accessed through methods.

No, they should almost always be private, only declare them protected when you absolutely need to access them in a child class. Most of the times you can just use your getters in the child class instead, if in doubt go with private properties and public getters and setters, and if at some point in the future you need protected properties, just update your API.

Related questions:

When are Getters and Setters Justified

When or why should one use getters/setters for class properties instead of simply making them public properties?

What is the point of properties?

When or why should one use getters/setters for class properties instead of simply making them public properties?

ContentLicense: CC BY-SA 3.0


问:
Is Entity Framework Suitable For High-Traffic Websites?
Is Entity Framework 4 a good solution for a public website with potentially 1000 hits/second?

In my understanding EF is a viable solution for mostly smaller or intranet websites, but wouldn't scale easily for something like a popular community website (I know SO is using LINQ to SQL, but.. I'd like more examples/proof...)

Now I am standing at the crossroads of either choosing a pure ADO.NET approach or EF4. Do you think the improved developer productivity with EF is worth the lost performance and granular access of ADO.NET (with stored procedures)? Any serious issues that a high traffic website might face, was it using EF?

Thank you in advance.

答:
Edit: Based on @Aaronaught great answer I'm adding few points targeting performance with EF. Those new points are prefixed by Edit.

The biggest improvement in performance in high traffic websites is achieved by caching (= first of all avoiding any web server processing or database querying) followed by asynchronous processing to avoid thread blocking while database queries are performed.

There is no bullet proof answer to your question because it always depends on requirements for application and on complexity of queries. The truth is that developer productivity with EF hides complexity behind which in many cases leads to incorrect usage of EF and terrible performance. The idea that you can expose high level abstracted interface for data access and it will smoothly works in all cases doesn't work. Even with ORM you must know what is happening behind the abstraction and how to correctly use it.

If you don't have previous experience with EF you will meet a lot of challenges when dealing with performance. You can make much more mistakes when working with EF comparing to ADO.NET. Also there is a lot of additional processing done in EF, so EF will always be significantly slower than native ADO.NET - that is something you can measure by simple proof of concept application.

If you want to get best performance from EF you will most probably have to:

Very carefully revise your data access with SQL profiler and review your LINQ queries if they correctly use Linq-to-entities instead of Linq-to-objects

Very carefully use advanced EF optimization features like MergeOption.NoTracking

Use ESQL in some cases

Pre-compile queries which are executed often

Think about taking advantage of EF Caching wrapper to get "second level cache" like feature for some queries

Use SQL views or custom mapped SQL queries (requires manual maintaining of EDMX file) in some scenarios for often used projections or aggregations which needs performance improvements

Use native SQL and stored procedures for some queries which don't provide sufficient performance when defined in Linq or ESQL

Edit: Carefully use queries - every query makes separate roundtrip to the database. EFv4 has no query batching because it is not able to use multiple result sets per executed database command. EFv4.5 will support multiple result sets for mapped stored procedures.

Edit: Carefully work with data modifications. Again EF completely lacks command batching. So in ADO.NET you can use single SqlCommand containing multiple insert, updates or deletes but with EF every such command will be executed in separate roundtrip to database.

Edit: Carefully work with identity map / identity cache. EF has special method (GetByKey in ObjectContext API or Find in DbContext API) to query the cache first. If you use Linq-to-entities or ESQL it will create roundtrip to the database and after that it will return existing instance from the cache.

Edit: Carefully use eager loading. It is not always win-win solution because it produces one huge dataset.
As you can see it is a lot of additional complexity and that is the whole point. ORM makes mapping and materialization simpler but when dealing with performance it will make it much more complex and you will have to make trade-offs.

I'm not sure if SO is still using L2S. They developed new open source ORM called Dapper and I think the main point behind this development was increasing performance.

OwnerDisplayName: niaher

OwnerDisplayName: Ladislav Mrnka


答:
The question "which ORM should I use" is really targeting the tip of a huge iceberg when it comes to the overall data access strategy and performance optimization in a large scale application.

All of the following things (roughly in order of importance) are going to affect throughput, and all of them are handled (sometimes in different ways) by most of the major ORM frameworks out there:

Database Design and Maintenance

This is, by a wide margin, the single most important determinant of the throughput of a data-driven application or web site, and often totally ignored by programmers.

If you don't use proper normalization techniques, your site is doomed. If you don't have primary keys, almost every query will be dog-slow. If you use well-known anti-patterns such as using tables for Key-Value Pairs (AKA Entity-Attribute-Value) for no good reason, you'll explode the number of physical reads and writes.

If you don't take advantage of the features the database gives you, such as page compression, FILESTREAM storage (for binary data), SPARSE columns, hierarchyid for hierarchies, and so on (all SQL Server examples), then you will not see anywhere near the performance that you could be seeing.

You should start worrying about your data access strategy after you've designed your database and convinced yourself that it's as good as it possibly can be, at least for the time being.

Eager vs. Lazy Loading

Most ORMs used a technique called lazy loading for relationships, which means that by default it will load one entity (table row) at a time, and make a round-trip to the database every time it needs to load one or many related (foreign key) rows.

This isn't a good or bad thing, it rather depends on what's actually going to be done with the data, and how much you know up-front. Sometimes lazy-loading is absolutely the right thing to do. NHibernate, for example, may decide not to query for anything at all and simply generate a proxy for a particular ID. If all you ever need is the ID itself, why should it ask for more? On the other hand, if you are trying to print a tree of every single element in a 3-level hierarchy, lazy-loading becomes an O(N²) operation, which is extremely bad for performance.

One interesting benefit to using "pure SQL" (i.e. raw ADO.NET queries/stored procedures) is that it basically forces you to think about exactly what data is necessary to display any given screen or page.  ORMs and lazy-loading features don't prevent you from doing this, but they do give you the opportunity to be... well, lazy, and accidentally explode the number of queries you execute.  So you need to understand your ORMs eager-loading features and be ever vigilant about the number of queries you're sending to the server for any given page request.

Caching

All major ORMs maintain a first-level cache, AKA "identity cache", which means that if you request the same entity twice by its ID, it doesn't require a second round-trip, and also (if you designed your database correctly) gives you the ability to use optimistic concurrency.

The L1 cache is pretty opaque in L2S and EF, you kind of have to trust that it's working. NHibernate is more explicit about it (Get/Load vs. Query/QueryOver). Still, as long as you try to query by ID as much as possible, you should be fine here. A lot of people forget about the L1 cache and repeatedly look up the same entity over and over again by something other than its ID (i.e. a lookup field). If you need to do this then you should save the ID or even the entire entity for future lookups.

There's also a level 2 cache ("query cache"). NHibernate has this built-in. Linq to SQL and Entity Framework have compiled queries, which can help reduce app server loads quite a bit by compiling the query expression itself, but it doesn't cache the data. Microsoft seems to consider this an application concern rather than a data-access concern, and this is a major weak point of both L2S and EF. Needless to say it's also a weak point of "raw" SQL. In order to get really good performance with basically any ORM other than NHibernate, you need to implement your own caching façade.

There's also an L2 cache "extension" for EF4 which is okay, but not really a wholesale replacement for an application-level cache.

Number of Queries

Relational databases are based on sets of data. They're really good at producing large amounts of data in a short amount of time, but they're nowhere near as good in terms of query latency because there's a certain amount of overhead involved in every command.  A well-designed app should play to the strengths of this DBMS and try to minimize the number of queries and maximize the amount of data in each.

Now I'm not saying to query the entire database when you only need one row. What I'm saying is, if you need the Customer, Address, Phone, CreditCard, and Order rows all at the same time in order to serve a single page, then you should ask for them all at the same time, don't execute each query separately. Sometimes it's worse than that, you'll see code that queries the same Customer record 5 times in a row, first to get the Id, then the Name, then the EmailAddress, then... it's ridiculously inefficient.

Even if you need to execute several queries that all operate on completely different sets of data, it's usually still more efficient to send it all to the database as a single "script" and have it return multiple result sets. It's the overhead you're concerned with, not the total amount of data.

This might sound like common sense but it's often really easy to lose track of all the queries that are being executed in various parts of the application; your Membership Provider queries the user/role tables, your Header action queries the shopping cart, your Menu action queries the site map table, your Sidebar action queries the featured product list, and then maybe your page is divided into a few separate autonomous areas which query the Order History, Recently Viewed, Category, and Inventory tables separately, and before you know it, you're executing 20 queries before you can even start to serve the page. It just utterly destroys performance.

Some frameworks - and I'm thinking mainly of NHibernate here - are incredibly clever about this and allow you to use something called futures which batch up entire queries and try to execute them all at once, at the last possible minute. AFAIK, you're on your own if you want to do this with any of the Microsoft technologies; you have to build it into your application logic.

Indexing, Predicates, and Projections

At least 50% of devs I speak to and even some DBAs seem to have trouble with the concept of covering indexes. They think, "well, the Customer.Name column is indexed, so every lookup I do on the name should be fast." Except it doesn't work that way unless the Name index covers the specific column you're looking up. In SQL Server, that's done with INCLUDE in the CREATE INDEX statement.

If you naïvely use SELECT * everywhere - and that is more or less what every ORM will do unless you explicitly specify otherwise using a projection - then the DBMS may very well choose to completely ignore your indexes because they contain non-covered columns. A projection means that, for example, instead of doing this:

```<code>from c in db.Customers where c.Name == "John Doe" select c
</code>```

You do this instead:

```<code>from c in db.Customers where c.Name == "John Doe"
select new { c.Id, c.Name }
</code>```

And this will, for most modern ORMs, instruct it to only go and query the Id and Name columns which are presumably covered by the index (but not the Email, LastActivityDate, or whatever other columns you happened to stick in there).

It's also very easy to completely blow away any indexing benefits by using inappropriate predicates.  For example:

```<code>from c in db.Customers where c.Name.Contains("Doe")
</code>```

...looks almost identical to our previous query but in fact will result in a full table or index scan because it translates to LIKE '%Doe%'.  Similarly, another query which looks suspiciously simple is:

```<code>from c in db.Customers where (maxDate == null) || (c.BirthDate >= maxDate)
</code>```

Assuming you have an index on BirthDate, this predicate has a good chance to render it completely useless. Our hypothetical programmer here has obviously attempted to create a kind of dynamic query ("only filter the birth date if that parameter was specified"), but this isn't the right way to do it. Written like this instead:

```<code>from c in db.Customers where c.BirthDate >= (maxDate ?? DateTime.MinValue)
</code>```

...now the DB engine knows how to parameterize this and do an index seek. One minor, seemingly insignificant change to the query expression can drastically affect performance.

Unfortunately LINQ in general makes it all too easy to write bad queries like this because sometimes the providers are able to guess what you were trying to do and optimize the query, and sometimes they aren't. So you end up with frustratingly inconsistent results which would have been blindingly obvious (to an experienced DBA, anyway) had you just written plain old SQL.

Basically it all comes down to the fact that you really have to keep a close eye on both the generated SQL and the execution plans they lead to, and if you're not getting the results you expect, don't be afraid to bypass the ORM layer once in a while and hand-code the SQL. This goes for any ORM, not just EF.

Transactions and Locking

Do you need to display data that's current up to the millisecond? Maybe - it depends - but probably not. Sadly, Entity Framework doesn't give you nolock, you can only use READ UNCOMMITTED at the transaction level (not table level). In fact none of the ORMs are particularly reliable about this; if you want to do dirty reads, you have to drop down to the SQL level and write ad-hoc queries or stored procedures.  So what it boils down to, again, is how easy it is for you to do that within the framework.

Entity Framework has come a long way in this regard - version 1 of EF (in .NET 3.5) was god-awful, made it incredibly difficult to break through the "entities" abstraction, but now you have ExecuteStoreQuery and Translate, so it's really not too bad. Make friends with these guys because you'll be using them a lot.

There's also the issue of write locking and deadlocks and the general practice of holding locks in the database for as little time as possible. In this regard, most ORMs (including Entity Framework) actually tend to be better than raw SQL because they encapsulate the unit of Work pattern, which in EF is SaveChanges. In other words, you can "insert" or "update" or "delete" entities to your heart's content, whenever you want, secure in the knowledge that no changes will actually get pushed to the database until you commit the unit of work.

Note that a UOW is not analogous to a long-running transaction. The UOW still uses the optimistic concurrency features of the ORM and tracks all changes in memory. Not a single DML statement is emitted until the final commit. This keeps transaction times as low as possible. If you build your application using raw SQL, it's quite difficult to achieve this deferred behaviour.

What this means for EF specifically: Make your units of work as coarse as possible and don't commit them until you absolutely need to. Do this and you'll end up with much lower lock contention than you would using individual ADO.NET commands at random times.

In Conclusion:

EF is completely fine for high-traffic/high-performance applications, just like every other framework is fine for high-traffic/high-performance applications. What matters is how you use it. Here's a quick comparison of the most popular frameworks and what features they offer in terms of performance (legend: N = Not supported, P = Partial, Y = yes/supported):

```<code>                                | L2S | EF1 | EF4 | NH3 | ADO
                                +-----+-----+-----+-----+-----
Lazy Loading (entities)         |  N  |  N  |  N  |  Y  |  N
Lazy Loading (relationships)    |  Y  |  Y  |  Y  |  Y  |  N
Eager Loading (global)          |  N  |  N  |  N  |  Y  |  N
Eager Loading (per-session)     |  Y  |  N  |  N  |  Y  |  N
Eager Loading (per-query)       |  N  |  Y  |  Y  |  Y  |  Y
Level 1 (Identity) Cache        |  Y  |  Y  |  Y  |  Y  |  N
Level 2 (Query) Cache           |  N  |  N  |  P  |  Y  |  N
Compiled Queries                |  Y  |  P  |  Y  |  N  | N/A
Multi-Queries                   |  N  |  N  |  N  |  Y  |  Y
Multiple Result Sets            |  Y  |  N  |  P  |  Y  |  Y
Futures                         |  N  |  N  |  N  |  Y  |  N
Explicit Locking (per-table)    |  N  |  N  |  N  |  P  |  Y
Transaction Isolation Level     |  Y  |  Y  |  Y  |  Y  |  Y
Ad-Hoc Queries                  |  Y  |  P  |  Y  |  Y  |  Y
Stored Procedures               |  Y  |  P  |  Y  |  Y  |  Y
Unit of Work                    |  Y  |  Y  |  Y  |  Y  |  N
</code>```

As you can see, EF4 (the current version) doesn't fare too badly, but it's probably not the best if performance is your primary concern. NHibernate is much more mature in this area and even Linq to SQL provides some performance-enhancing features that EF still doesn't.  Raw ADO.NET is often going to be faster for very specific data-access scenarios, but, when you put all the pieces together, it really doesn't offer a lot of important benefits that you get from the various frameworks.

And, just to make completely sure that I sound like a broken record, none of this matters in the slightest if you don't design your database, application, and data access strategies properly. All of the items in the chart above are for improving performance beyond the baseline; most of the time, the baseline itself is what needs the most improvement.

Title: Is Entity Framework Suitable For High-Traffic Websites?

Body:
Is Entity Framework 4 a good solution for a public website with potentially 1000 hits/second?

In my understanding EF is a viable solution for mostly smaller or intranet websites, but wouldn't scale easily for something like a popular community website (I know SO is using LINQ to SQL, but.. I'd like more examples/proof...)

Now I am standing at the crossroads of either choosing a pure ADO.NET approach or EF4. Do you think the improved developer productivity with EF is worth the lost performance and granular access of ADO.NET (with stored procedures)? Any serious issues that a high traffic website might face, was it using EF?

Thank you in advance.

Body:
The question "which ORM should I use" is really targeting the tip of a huge iceberg when it comes to the overall data access strategy and performance optimization in a large scale application.

All of the following things (roughly in order of importance) are going to affect throughput, and all of them are handled (sometimes in different ways) by most of the major ORM frameworks out there:

Database Design and Maintenance

This is, by a wide margin, the single most important determinant of the throughput of a data-driven application or web site, and often totally ignored by programmers.

If you don't use proper normalization techniques, your site is doomed. If you don't have primary keys, almost every query will be dog-slow. If you use well-known anti-patterns such as using tables for Key-Value Pairs (AKA Entity-Attribute-Value) for no good reason, you'll explode the number of physical reads and writes.

If you don't take advantage of the features the database gives you, such as page compression, FILESTREAM storage (for binary data), SPARSE columns, hierarchyid for hierarchies, and so on (all SQL Server examples), then you will not see anywhere near the performance that you could be seeing.

You should start worrying about your data access strategy after you've designed your database and convinced yourself that it's as good as it possibly can be, at least for the time being.

Eager vs. Lazy Loading

Most ORMs used a technique called lazy loading for relationships, which means that by default it will load one entity (table row) at a time, and make a round-trip to the database every time it needs to load one or many related (foreign key) rows.

This isn't a good or bad thing, it rather depends on what's actually going to be done with the data, and how much you know up-front. Sometimes lazy-loading is absolutely the right thing to do. NHibernate, for example, may decide not to query for anything at all and simply generate a proxy for a particular ID. If all you ever need is the ID itself, why should it ask for more? On the other hand, if you are trying to print a tree of every single element in a 3-level hierarchy, lazy-loading becomes an O(N²) operation, which is extremely bad for performance.

One interesting benefit to using "pure SQL" (i.e. raw ADO.NET queries/stored procedures) is that it basically forces you to think about exactly what data is necessary to display any given screen or page.  ORMs and lazy-loading features don't prevent you from doing this, but they do give you the opportunity to be... well, lazy, and accidentally explode the number of queries you execute.  So you need to understand your ORMs eager-loading features and be ever vigilant about the number of queries you're sending to the server for any given page request.

Caching

All major ORMs maintain a first-level cache, AKA "identity cache", which means that if you request the same entity twice by its ID, it doesn't require a second round-trip, and also (if you designed your database correctly) gives you the ability to use optimistic concurrency.

The L1 cache is pretty opaque in L2S and EF, you kind of have to trust that it's working. NHibernate is more explicit about it (Get/Load vs. Query/QueryOver). Still, as long as you try to query by ID as much as possible, you should be fine here. A lot of people forget about the L1 cache and repeatedly look up the same entity over and over again by something other than its ID (i.e. a lookup field). If you need to do this then you should save the ID or even the entire entity for future lookups.

There's also a level 2 cache ("query cache"). NHibernate has this built-in. Linq to SQL and Entity Framework have compiled queries, which can help reduce app server loads quite a bit by compiling the query expression itself, but it doesn't cache the data. Microsoft seems to consider this an application concern rather than a data-access concern, and this is a major weak point of both L2S and EF. Needless to say it's also a weak point of "raw" SQL. In order to get really good performance with basically any ORM other than NHibernate, you need to implement your own caching façade.

There's also an L2 cache "extension" for EF4 which is okay, but not really a wholesale replacement for an application-level cache.

Number of Queries

Relational databases are based on sets of data. They're really good at producing large amounts of data in a short amount of time, but they're nowhere near as good in terms of query latency because there's a certain amount of overhead involved in every command.  A well-designed app should play to the strengths of this DBMS and try to minimize the number of queries and maximize the amount of data in each.

Now I'm not saying to query the entire database when you only need one row. What I'm saying is, if you need the Customer, Address, Phone, CreditCard, and Order rows all at the same time in order to serve a single page, then you should ask for them all at the same time, don't execute each query separately. Sometimes it's worse than that, you'll see code that queries the same Customer record 5 times in a row, first to get the Id, then the Name, then the EmailAddress, then... it's ridiculously inefficient.

Even if you need to execute several queries that all operate on completely different sets of data, it's usually still more efficient to send it all to the database as a single "script" and have it return multiple result sets. It's the overhead you're concerned with, not the total amount of data.

This might sound like common sense but it's often really easy to lose track of all the queries that are being executed in various parts of the application; your Membership Provider queries the user/role tables, your Header action queries the shopping cart, your Menu action queries the site map table, your Sidebar action queries the featured product list, and then maybe your page is divided into a few separate autonomous areas which query the Order History, Recently Viewed, Category, and Inventory tables separately, and before you know it, you're executing 20 queries before you can even start to serve the page. It just utterly destroys performance.

Some frameworks - and I'm thinking mainly of NHibernate here - are incredibly clever about this and allow you to use something called futures which batch up entire queries and try to execute them all at once, at the last possible minute. AFAIK, you're on your own if you want to do this with any of the Microsoft technologies; you have to build it into your application logic.

Indexing, Predicates, and Projections

At least 50% of devs I speak to and even some DBAs seem to have trouble with the concept of covering indexes. They think, "well, the Customer.Name column is indexed, so every lookup I do on the name should be fast." Except it doesn't work that way unless the Name index covers the specific column you're looking up. In SQL Server, that's done with INCLUDE in the CREATE INDEX statement.

If you naïvely use SELECT * everywhere - and that is more or less what every ORM will do unless you explicitly specify otherwise using a projection - then the DBMS may very well choose to completely ignore your indexes because they contain non-covered columns. A projection means that, for example, instead of doing this:

from c in db.Customers where c.Name == "John Doe" select c

You do this instead:

from c in db.Customers where c.Name == "John Doe"
select new { c.Id, c.Name }

And this will, for most modern ORMs, instruct it to only go and query the Id and Name columns which are presumably covered by the index (but not the Email, LastActivityDate, or whatever other columns you happened to stick in there).

It's also very easy to completely blow away any indexing benefits by using inappropriate predicates.  For example:

from c in db.Customers where c.Name.Contains("Doe")

...looks almost identical to our previous query but in fact will result in a full table or index scan because it translates to LIKE '%Doe%'.  Similarly, another query which looks suspiciously simple is:

from c in db.Customers where (maxDate == null) || (c.BirthDate >= maxDate)

Assuming you have an index on BirthDate, this predicate has a good chance to render it completely useless. Our hypothetical programmer here has obviously attempted to create a kind of dynamic query ("only filter the birth date if that parameter was specified"), but this isn't the right way to do it. Written like this instead:

from c in db.Customers where c.BirthDate >= (maxDate ?? DateTime.MinValue)

...now the DB engine knows how to parameterize this and do an index seek. One minor, seemingly insignificant change to the query expression can drastically affect performance.

Unfortunately LINQ in general makes it all too easy to write bad queries like this because sometimes the providers are able to guess what you were trying to do and optimize the query, and sometimes they aren't. So you end up with frustratingly inconsistent results which would have been blindingly obvious (to an experienced DBA, anyway) had you just written plain old SQL.

Basically it all comes down to the fact that you really have to keep a close eye on both the generated SQL and the execution plans they lead to, and if you're not getting the results you expect, don't be afraid to bypass the ORM layer once in a while and hand-code the SQL. This goes for any ORM, not just EF.

Transactions and Locking

Do you need to display data that's current up to the millisecond? Maybe - it depends - but probably not. Sadly, Entity Framework doesn't give you nolock, you can only use READ UNCOMMITTED at the transaction level (not table level). In fact none of the ORMs are particularly reliable about this; if you want to do dirty reads, you have to drop down to the SQL level and write ad-hoc queries or stored procedures.  So what it boils down to, again, is how easy it is for you to do that within the framework.

Entity Framework has come a long way in this regard - version 1 of EF (in .NET 3.5) was god-awful, made it incredibly difficult to break through the "entities" abstraction, but now you have ExecuteStoreQuery and Translate, so it's really not too bad. Make friends with these guys because you'll be using them a lot.

There's also the issue of write locking and deadlocks and the general practice of holding locks in the database for as little time as possible. In this regard, most ORMs (including Entity Framework) actually tend to be better than raw SQL because they encapsulate the unit of Work pattern, which in EF is SaveChanges. In other words, you can "insert" or "update" or "delete" entities to your heart's content, whenever you want, secure in the knowledge that no changes will actually get pushed to the database until you commit the unit of work.

Note that a UOW is not analogous to a long-running transaction. The UOW still uses the optimistic concurrency features of the ORM and tracks all changes in memory. Not a single DML statement is emitted until the final commit. This keeps transaction times as low as possible. If you build your application using raw SQL, it's quite difficult to achieve this deferred behaviour.

What this means for EF specifically: Make your units of work as coarse as possible and don't commit them until you absolutely need to. Do this and you'll end up with much lower lock contention than you would using individual ADO.NET commands at random times.

In Conclusion:

EF is completely fine for high-traffic/high-performance applications, just like every other framework is fine for high-traffic/high-performance applications. What matters is how you use it. Here's a quick comparison of the most popular frameworks and what features they offer in terms of performance (legend: N = Not supported, P = Partial, Y = yes/supported):

                                | L2S | EF1 | EF4 | NH3 | ADO
                                +-----+-----+-----+-----+-----
Lazy Loading (entities)         |  N  |  N  |  N  |  Y  |  N
Lazy Loading (relationships)    |  Y  |  Y  |  Y  |  Y  |  N
Eager Loading (global)          |  N  |  N  |  N  |  Y  |  N
Eager Loading (per-session)     |  Y  |  N  |  N  |  Y  |  N
Eager Loading (per-query)       |  N  |  Y  |  Y  |  Y  |  Y
Level 1 (Identity) Cache        |  Y  |  Y  |  Y  |  Y  |  N
Level 2 (Query) Cache           |  N  |  N  |  P  |  Y  |  N
Compiled Queries                |  Y  |  P  |  Y  |  N  | N/A
Multi-Queries                   |  N  |  N  |  N  |  Y  |  Y
Multiple Result Sets            |  Y  |  N  |  P  |  Y  |  Y
Futures                         |  N  |  N  |  N  |  Y  |  N
Explicit Locking (per-table)    |  N  |  N  |  N  |  P  |  Y
Transaction Isolation Level     |  Y  |  Y  |  Y  |  Y  |  Y
Ad-Hoc Queries                  |  Y  |  P  |  Y  |  Y  |  Y
Stored Procedures               |  Y  |  P  |  Y  |  Y  |  Y
Unit of Work                    |  Y  |  Y  |  Y  |  Y  |  N

As you can see, EF4 (the current version) doesn't fare too badly, but it's probably not the best if performance is your primary concern. NHibernate is much more mature in this area and even Linq to SQL provides some performance-enhancing features that EF still doesn't.  Raw ADO.NET is often going to be faster for very specific data-access scenarios, but, when you put all the pieces together, it really doesn't offer a lot of important benefits that you get from the various frameworks.

And, just to make completely sure that I sound like a broken record, none of this matters in the slightest if you don't design your database, application, and data access strategies properly. All of the items in the chart above are for improving performance beyond the baseline; most of the time, the baseline itself is what needs the most improvement.

OwnerDisplayName: Aaronaught


问:
How to improve your ability to debug existing code
A common task in the working world is dealing with existing, but buggy code. What are some tips to improve your skills as a debugger?</p>

答:
Divide and conquer is a good approach. Try to identify some visible input (user input/network event ...) and output (log, output to user, outbound network message ...) between which the issue exists. Try putting prints at sizable chunks or significant points between them and try to narrow down where the bug is in the code.

Divide and conquer can also work very well in case of regressions over version controlled code. Find two builds - one where it works as expected, other with the regression. Narrow the gap down till you are left with a bunch of checkins as potential suspects.

ContentLicense: CC BY-SA 2.5


答:
It depends a bit on how much abstraction you need. Everything is a compromise; for example, EF and NHibernate introduce great flexibility for representing the data in interesting and exotic models - but as a result they do add overhead. Noticeable overhead.

If you don't need to be able to switch between database providers, and different per-client table layouts, and if your data is primarily read, and if you don't need to be able to use the same model in EF, SSRS, ADO.NET Data Services, etc - then if you want absolute performance as your key measure you could do far worse than look at dapper. In our tests based on both LINQ-to-SQL and EF, we find that EF is significantly slower in terms of raw read performance, presumably due to the abstraction layers (between storage model etc) and materialization.

Here at SO, we are obsessive-compulsive about raw performance, and we're happy to take the development hit of losing some abstraction in order to gain speed. As such, our primary tool for querying the database is dapper. This even allows us to use our pre-existing LINQ-to-SQL model, but simply: it is heaps faster. In performance tests, it is essentially exactly the same performance as writing all the ADO.NET code (parameters, data-readers etc) manually, but without the risk of getting a column name wrong. It is, however, SQL based (although it is happy to use SPROCs if that is your chosen poison). The advantage of this is that there is no additional processing involved, but it is a system for people who like SQL. Which I consider: not a bad thing!

A typical query, for example, might be:

```<code>int customerId = ...
var orders = connection.Query<Order>(
    "select * from Orders where CustomerId = @customerId ",
    new { customerId }).ToList();
</code>```

which is convenient, injection-safe, etc - but without tons of data-reader goo. Note that while it can handle both horizontal and vertical partitions to load complex structures, it will not support lazy-loading (but: we're big fans of very explicit loading - fewer surprises).

Note in this answer I am not saying that EF isn't suitable for high-volume work; simply: I know that dapper is up to it.

Body:
It depends a bit on how much abstraction you need. Everything is a compromise; for example, EF and NHibernate introduce great flexibility for representing the data in interesting and exotic models - but as a result they do add overhead. Noticeable overhead.

If you don't need to be able to switch between database providers, and different per-client table layouts, and if your data is primarily read, and if you don't need to be able to use the same model in EF, SSRS, ADO.NET Data Services, etc - then if you want absolute performance as your key measure you could do far worse than look at dapper. In our tests based on both LINQ-to-SQL and EF, we find that EF is significantly slower in terms of raw read performance, presumably due to the abstraction layers (between storage model etc) and materialization.

Here at SO, we are obsessive-compulsive about raw performance, and we're happy to take the development hit of losing some abstraction in order to gain speed. As such, our primary tool for querying the database is dapper. This even allows us to use our pre-existing LINQ-to-SQL model, but simply: it is heaps faster. In performance tests, it is essentially exactly the same performance as writing all the ADO.NET code (parameters, data-readers etc) manually, but without the risk of getting a column name wrong. It is, however, SQL based (although it is happy to use SPROCs if that is your chosen poison). The advantage of this is that there is no additional processing involved, but it is a system for people who like SQL. Which I consider: not a bad thing!

A typical query, for example, might be:

int customerId = ...
var orders = connection.Query<Order>(
    "select * from Orders where CustomerId = @customerId ",
    new { customerId }).ToList();

which is convenient, injection-safe, etc - but without tons of data-reader goo. Note that while it can handle both horizontal and vertical partitions to load complex structures, it will not support lazy-loading (but: we're big fans of very explicit loading - fewer surprises).

Note in this answer I am not saying that EF isn't suitable for high-volume work; simply: I know that dapper is up to it.

OwnerDisplayName: Marc Gravell


问:
How can I provide guidance on technology choices through user stories?
I'm a project manager for a team of firmware engineers making the transition to adopting Scrum and I'm moving to support the team in a Product Owner role. We've just gone through Scrum training and are beginning a month of coaching which is going to be invaluable. Coming from a technical background I can already see the challenge of shifting my point of view from the solution domain to focusing on business value. For me it's very tempting to think of "how" to solve a problem. But I like the concept of user stories and defining vertical slices of functionality that give value to the customer and letting the team determine the "how".

Forgive me if this is a naive question, but as the PO how can I provide guidance on specific technical direction through user stories? My concern is that in some cases without guidance the team may head down the wrong path on key technical decisions.

As a simplistic example I might have a user story:

As a clinician I want the device to record information about the patient's treatment so that I can determine if the patient's therapy has been effective.

Now say time to market is critical and I want to fork out for an off-the-shelf file system stack to save time, what conveys that to the team? They might go off and start writing their own stack from scratch.

Is this sort of guidance provided through:

Conversations during sprint planning and backlog grooming? But if so, is it my place as the PO to even be suggesting how to solve a problem.

Acceptance criteria? I don't really like this, I have a bad feeling about making acceptance criteria so prescriptive that they specify how to solve a problem.

Constraints?

Thanks in advance. I could (and will) ask our Scrum coach but I won't be able to do that before Monday and this question has been really bugging me :)

答:
Don't suggest how to solve the problem, but DO communicate what are the driving business motivations for the story.

IMHO, a key responsibility of a PO is to effectively communicate the business and market context to the team so that they can make valid, informed decisions.

In this case, time to market is critical, so communicate that to the team: "This story is very important for business that we want to get out really soon, so consider if we can just use some off the shelf solution or third party library."

Then leave it to the team to make the decision. They might find that writing their own is really faster, or maybe integrating a third party solution is faster, so let them investigate and decide.

A good team can change their implementation strategy to align with the business need. But, they may not understand that business need. As a PO you need to bridge that gap.

OwnerDisplayName: Jono


问:
Is there a way to combat Sales perpetually overcommitting?
I seem to be repeatedly stuck in a situation where release dates are set not based on anything technical, but because someone in Sales has committed to a customer by then.  Based on discussions with friends in development at other companies, the same thing seems to happen.

"Here is the committed feature set and here is the committed release date", and it's difficult to argue because at this point there is money riding on it, and that trumps everything.

In general, is there a way to push back on this?  If not for this release, what about in future?  The problem I have is that the only way I see one way of doing so, and that's by doing the best I can, but release the software 'as is', so to speak.

I don't want to release bug-ridden software since it's my name attached, but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date.

edit: for the record, I'm not doing 80 hour weeks now, just that comes to mind as what would be required to cover the expected feature set by the release date.

答:
Some very good answers here already. I will just add that you should not be driven to meet his deadlines to your own detriment. Also, I would definitely have a word with the sales person and remind him that if he over-promises and the company cannot deliver on his promises then he (and the company) will not be trusted in the future, losing him future commissions (and possibly his job), so it is in his best interest to be realistic (i.e. consult with programming staff) so that he gains trust in the company. In the short term he may gain by being unrealistic, but in the long term he will lose out by damaging his reputation with customers, his employer and future employers via bad references.

As sales people understand money more than anything else, talk to him in those terms.


问:
Who owns the code I wrote, what rights do I have with respect to my employer
This is a legal question with mixing code I've written in my own time with code I've been paid to write for an employer.

I'm employed at a company with an employment contract, and am paid hourly. This is in Ontario, Canada in case that that affects matters.

I've been working on a project for my employer, and in this project I've incorporated some code that I had previously written in my own time at my house for another project (as in I own the code outright).

My code is now tightly coupled with the project at work (as in it won't work without it). I have at times needed to make changes to my original code to get it working with my work project, and since I am paid hourly for my time, I've technically been paid to work on my own code.

But since I was paid for it, does my employer now technically own this code?

Suppose I leave this company tomorrow, do I need to leave my source code behind? I'm not saying I would, but do I still retain exclusive and unrestricted rights to my original code?

答:
I'm not a lawyer, but it sounds like there's a chance things are kind of a mess.  Your contract probably says your employer owns the code you do on their time, and maybe the code you do on your time as well.

If your employer owns the parts you did on their time but not the rest, and you own the parts you did on your time, and if isn't 100% clear which parts were done when, then it's possible that neither you nor your employer enough legal rights to enough of the code to be able to use it with confidence.

Because things like this aren't unknown, there is a fairly good chance that something in your contract gives them ownership of the code you wrote in your own time.  And even if you still own some of the code you wrote in your own time, you have to consider the possibility that your employer could later try to claim ownership of your project because it's based on code they own.  Which means if you sell the code without disclosing that you might not own it, you might be accused of acting in bad faith, or I suppose of fraud.  And who will buy it if they aren't sure you own it?

These are just some of the things I can think of that might go wrong, but it seems like a complicated legal question to me, so I really don't know.

On the good side, probably your employer isn't out to steal your code and you aren't out to steal theirs, so it seems like there is a good chance you could resolve it all amicably in any case, even after the fact.  Your employer may well let you have whatever intellectual property rights it feels it can give you while still protecting it's own interests.


问:
Is there a good reason to avoid node.js for non-realtime web apps?
I've seen a lot of talk about how awesome Node.js is for realtime web apps -- things that need sockets, Comet, AJAX-heavy communications, and so forth. I know that its event-driven, asynchronous, thread-driven model is also good for concurrency with low overhead.

I've also seen Node.js tutorials for more simple, 'traditional', non-realtime apps (e.g., the standard blog example, which seems to be the standard 'Hello World' for people learning app development). And I also know that node-static allows you to serve static assets.

My question is: is there any good reason to avoid Node.js for traditional web apps, like classifieds, forums, the aforementioned blog example, or the sort of CRUD apps you build for internal business applications? Just because it excels at all the funky realtime stuff, does that contraindicate it for more staid uses?

The only thing I can think of, off the bat, is the lack of mature libraries (although that's changing).

(The reason I'm asking is that I'm considering ditching PHP for Node.js, mostly to get over the impedance mismatch of switching between languages, but also so I can reuse validation code and whatnot. My superego admonishes me to choose the best tool for the job; however, I don't have a lot of time to learn fifteen languages and all their userland libraries just to have a comprehensive arsenal. It's also reassuring that Node.js might give me an easier optimisation path than PHP/Apache in the future when I have to start thinking about heavy traffic.)

[EDIT] Thanks for the answers so far, folks; I just want to see if anyone else will weigh in before I choose an answer. The answer from @Raynos kinda confirms what I'm thinking, and the links from the commenters provided good food for thought, but I want to see if anyone else has any Node-specific answers, like 'DON'T USE NODE FOR PROBLEM X'. (Besides high-CPU tasks; I know that already :-)

答:
is there any good reason to avoid Node.js for traditional web apps

Yes, if you have N years in web platform X then clearly you can developer an application in platform X faster.

If you want to do Y and platform X has a pre-made solution Y that does X then do so.

All the generic reasons of why you should use one platform over another.

the sort of CRUD apps you build for internal business applications?

Yes there are other platform that let you write a generic application faster, ruby on rails comes to mind.

However, that said. I have experience with node and can't claim I would choose another platform over node unless it does a massive amount of features out of the box for me.

Basically it's a simple question of

Does a tool exists that does all of this for me? No, then pick the most convenient platform to write the tool.

There are no solid reasons why node.js is an inconvenient platform (other then "i hate javascript")


答:
Spec the job after they give it to you and let them know how long it will take.  Then when they crow about it tell them.

"I'm sorry you made that commitment but given the resources at my disposal It will take X hours to complete"

Do this every time...it worked for me.

Basically tell them they can have it Fast, Cheap and Good, pick two.

Title: Is there a way to combat Sales perpetually overcommitting?

Body:
I seem to be repeatedly stuck in a situation where release dates are set not based on anything technical, but because someone in Sales has committed to a customer by then.  Based on discussions with friends in development at other companies, the same thing seems to happen.

"Here is the committed feature set and here is the committed release date", and it's difficult to argue because at this point there is money riding on it, and that trumps everything.

In general, is there a way to push back on this?  If not for this release, what about in future?  The problem I have is that the only way I see one way of doing so, and that's by doing the best I can, but release the software 'as is', so to speak.

I don't want to release bug-ridden software since it's my name attached, but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date.

edit: for the record, I'm not doing 80 hour weeks now, just that comes to mind as what would be required to cover the expected feature set by the release date.


答:
As with others, I am not a lawyer but have been involved in some interesting questions like this ... in my opine (and ONLY my opinion) this is where your argument likely fails:

as in I own the code outright

The minute you put it in your employers code-base, even if you had developed it PRIOR to joining the company, you forfeit your right of ownership.

The other thing to consider is even if you are LEGALLY in the right, what is it worth to you to defend?  If you did leave the company, and they decided to come after you hard, how much would it cost you to PROVE ownership? Likely they could (and if were the churlish type would) bury you in court costs, making it not worth time/cost to exert privilege.

Title: Who owns the code I wrote, what rights do I have with respect to my employer

Body:
This is a legal question with mixing code I've written in my own time with code I've been paid to write for an employer.

I'm employed at a company with an employment contract, and am paid hourly. This is in Ontario, Canada in case that that affects matters.

I've been working on a project for my employer, and in this project I've incorporated some code that I had previously written in my own time at my house for another project (as in I own the code outright).

My code is now tightly coupled with the project at work (as in it won't work without it). I have at times needed to make changes to my original code to get it working with my work project, and since I am paid hourly for my time, I've technically been paid to work on my own code.

But since I was paid for it, does my employer now technically own this code?

Suppose I leave this company tomorrow, do I need to leave my source code behind? I'm not saying I would, but do I still retain exclusive and unrestricted rights to my original code?


答:
No

I tried to make this a two letter answer and the stack wouldn't let me ... but the answer is

No

Which, isn't completely true if you own / run the company, of course. If you're in that position you can drag the sales team in by the ears and "have the talk". If, however and as I suspect, you are just a "lowly" technical person your only recourse is to complain "UP" the chain of command.  That being said, my experience has been that in companies where this happens, management is aware of situation and doesn't care.


答: Keep debugging. If you debug a lot, you'll improve.</p>

Title: How to improve your ability to debug existing code

Body: A common task in the working world is dealing with existing, but buggy code. What are some tips to improve your skills as a debugger?</p>


答: I don't think your concern applies to Ruby or other languages that support properties.  In Ruby, you can attach any desired behavior to the setting of a property, by defining an accessor.  This affords clients a convenient syntax while giving the class designer complete control over the behavior.  Set and get methods are unnecessary in Ruby.</p>

Body:
Should ActiveRecord-based domain models have visible properties? Why or why not?

My experience and studies have always lead me to believe that object properties should always be protected, and that data should only be manipulated/accessed through methods. This ensures that if the internals of the class need to be refactored, other objects that rely on that object do not then also need to be refactored.

I often see domain models with publicly visible properties however, and the models can be passed to say view objects which directly access those properties while building the view. I have always thought that this is perhaps the one exception to the above mentioned rule, because otherwise you would basically have to create getters and setters for objects like the view to use, or some other equally troubling sounding solution. Perhaps I am wrong on this? I would like to get some feedback on the subject.


问:
How can I get my startup working with Agile development?
In our startup, we've worked until now using the traditional waterfall model, but we want to try our next project using Agile Methodology.

We are pretty much alien to the entire Agile process, so considering this, what is the best way to understand Agile (resources and a practical handbook can be of help), decide on a specific methodology (Scrum, etc), and start it in our next project?

答:
I wouldn't start with the "I need to do agile" point of view.

Instead, look at your existing process and see how you can fix issues that you see. Continuous improvement, starting with what you are currently doing, is the key IMHO.

Why? A lot of "standard" agile process isn't well suited to a startup (funny as that sounds).

Instead, pick and choose practices that help solve your current problems, and plug in practices one by one as and when you need them.

At a meta level:

Focus on feedback. A startup lives and dies on how well you can respond to user feedback and how well you can iterate.  This means being able to quickly develop a feature and put it into production. Choose practices that help you build faster and deploy easier.

In a startup 80% is "what to build", 20% is "how to build". Focus on practices that help you decide "what to build"

At a practice level:

Investigate user story mapping. This is a technique that allows you to understand the scope of what you are trying to build. Very useful for keeping in mind the vision and the "big picture" of what you are doing.

Automated testing is a good idea. Learn about unit testing frameworks like jUnit etc (there is one such framework for every programming language, google " unit testing").

Focus on one feature at a time. Don't build multiple features in parallel.

And if you read a book or attend a training on scrum or agile, then these are the parts that I wouldn't use

Estimations: A startup rarely needs to do long term planning or roadmaps. Even a 3 month roadmap is likely to get out of date. So dont bother with estimations, its just a waste of time. You will hear about story points and all sorts of complicated things. Just forget it all.

Iterations/Sprints: Too much overhead for startups.

Instead, I'd do something like this:

Get a piece of paper. Write down the features you want to implement (these can come from the user story mapping technique I mentioned above)

Pick one feature that you want to implement next

Everyone works on this feature

Deploy the feature

Look at the user / customer reaction

Go back to the story map / feature list with your new learning and make changes to the story map / feature list if needed

Go back to step 2

Once in a while see how you can improve. What problems did you have, and do you need to do anything differently, or add in new practices.

Thats it! You're agile now :)

OwnerDisplayName: andy


问:
How to trim emails for just the body, when using email as input to an external system?
When an application allows emails to be sent to it to either reply to comments or add todos, trimming those emails for just the relevant text becomes a problem, since there are many different standards.  Many times you'll end up seeing things like this:

Hey Joe, good to hear from you.  Let me know when you'll be back in town.

  Posted by Bob, 30 minutes ago

I'll be back on the 13th.

--

  Sincerely,

  Joseph R. Roberts

  Senior Partner

This communication is confidential and is property of Whatever Law Firm.

  Posted by Joe, 10 seconds ago

Signatures are probably the most difficult to get rid of, and quoted text the easiest.  I imagine any comprehensive strategy for trimming will be multi-facted, and ideally, learning.   I think a good system should:

Remove quoted body

Remove quote headers ("On 15 October, Joe wrote:")

Remove signatures

Preserve anything that was typed manually.

What steps would a system need to take to accomplish this, and what pitfalls should it be aware of?

This answer is a good example of a useful answer to a similar question

答:
You can just trim the email as people usually do with their eye lasers. Ignore quoted parts and signature.

But make sure to save a copy in case the trimming messes up. Or you can let the customer cut a few emails first and follow his/her habits.

However carefully and considerate, I don't think there's any way to make sure all emails are trimmed property. Some weird things manually written will be cut off.

(Or you can change the way emails are written - make marks while people actually type or copy and paste and preserve those parts. But this change may take a long time...)


答:
One suggestion that hasn't come up yet: retrospectives.

Don't say "no, I'm not doing overtime," that always encourages other developers to swoop in and make you look bad.

But do say very clearly to your management that every time you have to do more than 40 hours a week to get a job done, everyone involved in the project should sit down in a room after the product is delivered, figure out what went wrong and what we can do to stop it happening again. Or, better still, every project should have a retrospective to discuss what went well and what went wrong.

If you're right and it's salesmen overcommitting then this will become very clear very quickly. But don't preempt the conclusion and don't be adversarial ahead of the fact. Talk about it in terms of things your team can do to deliver on time without overtime.

You never know, you may even find improvements to your own processes which can make the salesperson's estimate more feasible.


问:
How to become a JavaScript ninja?
I want to choose JavaScript as my main development field, alongside HTML and CSS to become a developer commonly known as front-end developer. But I don't know how to become a JavaScript professional. I've read many books and learned the pieces including data types, syntax, tools usage (like IDEs, Debuggers, etc.), jQuery, etc. But when I look at some sophisticated JavaScript codes including famous libraries, I'm like "I never could write that code". What's wrong here? What step should I had taken that I didn't? I feel I'm missing something here to become a professional JavaScript developer.
I also watched training movies, including Douglas Crockford's movies at Yahoo Theater.

答:
The javascript code you find in a typical web application is fairly easy, especially if you use a framework like jQuery. Writing custom plugins is a little more advanced, but still only requires a few basic concepts. This is enough for most purposes - in enterprise environments you can really impress clients with a few simple techniques from internet development because the existing UI is usually awful - but not really ninja level.

If you want to really know javascript, you need something a bit more challenging where you will run into limitations of the system and be forced to apply more advanced techniques. You can find some of this sort of code in frameworks that have to deal with browser compatibility, but this is largely a solved problem, as well as being rather frustrating to work with. There are a lot of more interesting options around html5 apps - try to implement something that would not normally be done in a browser.

My own example of this is a git client. Javascript doesn't handle binary data very well, and the naive implementation locks the UI for several minutes and allocates new objects fast enough to run out of memory before GC is triggered. Optimizing something like this leads to learning exactly what happens when the code is run, and since this understanding is impossible with poorly structured code you will learn to write javascript with a clear structure that is applicable to more typical applications as well.

Title: How to become a JavaScript ninja?


答:
Ninja's are normally just farmers or peasants dressed up in simple but sneaky identity disguising garb. But what makes a simple person a true ninja is a meaningful objective, pulling it off and then not getting killed themselves. So with that in mind why don't you find a javascript samurai demon, sharpen you coding katana and see if you can take the badboy down without killing yourself.  If you succeed you'll make the world a better place for the other code farmers and find that you've become a ninja in the process. That or you'll be dead. </p>

<p>Good luck! </p>

Title: How to become a JavaScript ninja?

Body:
I want to choose JavaScript as my main development field, alongside HTML and CSS to become a developer commonly known as front-end developer. But I don't know how to become a JavaScript professional. I've read many books and learned the pieces including data types, syntax, tools usage (like IDEs, Debuggers, etc.), jQuery, etc. But when I look at some sophisticated JavaScript codes including famous libraries, I'm like "I never could write that code". What's wrong here? What step should I had taken that I didn't? I feel I'm missing something here to become a professional JavaScript developer.
I also watched training movies, including Douglas Crockford's movies at Yahoo Theater.

Body:
Ninja's are normally just farmers or peasants dressed up in simple but sneaky identity disguising garb. But what makes a simple person a true ninja is a meaningful objective, pulling it off and then not getting killed themselves. So with that in mind why don't you find a javascript samurai demon, sharpen you coding katana and see if you can take the badboy down without killing yourself.  If you succeed you'll make the world a better place for the other code farmers and find that you've become a ninja in the process. That or you'll be dead.

Good luck!


问:
What keywords are important to speedup the code in C++?
I'm porting to C++ and adding a lot of functionality to a numerical application written in Fortran 77. While I hate F77, I have to admit that the thing goes very fast. Now, I'm implementing practically the same structure and algorithm, but nevertheless the difference in the execution time is noticeable. Not big, but it's there. And I'm wondering, could it be that I need to pass extra information to the compiler? The only related information that I've been able to find is a recommendation to use the restrict key word which is supported by g++, but that's all. Hence, my question: Are there anymore keywords important to speedup code in C++ in numerical applications? or maybe compiler directives?

Thanks!

答:
Most of it is going to be in the design of the rewrite.  I've done F to C and F to C++ several times for commercial products and the biggest boogymen were:

Beware of allocation operations in node-based standard library iterators.

Knock out any pass by reference (pointers), remember that Fortran has the no-aliasing rule for pointers.  C and C++ do not, so if you end up with a function that looks like this:

```<code>int some_function(int* a, int* b)
{

     ...code...
     int some_intermediate_value = *a + *b;
     int other_value = *a + 7;
     ...and other code referencing b and a...

}
</code>```

...it will fetch a and b every time (because of aliasing rules).  Solvable by either changing the function signature and uses, or by copying to local temporaries inside the function (useful when doing a BIG refactor where it's tough to grab so many changes at once).

Body:
Most of it is going to be in the design of the rewrite.  I've done F to C and F to C++ several times for commercial products and the biggest boogymen were:

Beware of allocation operations in node-based standard library iterators.

Knock out any pass by reference (pointers), remember that Fortran has the no-aliasing rule for pointers.  C and C++ do not, so if you end up with a function that looks like this:

int some_function(int* a, int* b)
{

     ...code...
     int some_intermediate_value = *a + *b;
     int other_value = *a + 7;
     ...and other code referencing b and a...

}

...it will fetch a and b every time (because of aliasing rules).  Solvable by either changing the function signature and uses, or by copying to local temporaries inside the function (useful when doing a BIG refactor where it's tough to grab so many changes at once).


问:
Using Mercurial repository inside a Git one: Feasible? Sane?
I am thinking on creating a Mercurial repository under a Git repository.
e.g.

```<code>..../git-repository/directory/hg-repo/
</code>```

The 2 repositories

Is it possible to manage (keeping your sanity)? How similiar is it to this?

I am a computer science student at University. I manage my work in Git, mainly as a distribution mechanism (after realizing that rsync fails when you have changes in more than one place) between my desktop and usb drive. I try use of Git as a VCS as I do work.

I have finished a semester where I did a small group project to prepare for a larger group project next year. We had to use Subversion, and experienced the joys of a centralised VCS (including downtime).

I tried to keep the subversion repository separate to my Git repository for the subject**, however it was annoying that it was seperate (not in the place where I store assignments). I therefore moved to using an Subversion repository inside my Git repository.

As I think ahead (maybe I am thinking too far ahead) I realise that I will have to try and convince people to use a DVCS and Mercurial will probably be the one that is preferred (Windows and Mac GUI support, closer to Subversion).

Having done some research into the whole Git vs Mercurial debate (however not used Mercurial at all) I still prefer Git.

Can I have a Mercurial repository inside a Git one without going mad (or it ruining something)? Or is it something that I should not consider at all?

(Or is it a bad question that should be deleted?)

** I think outside of Australia it is called a course

答:
No need to maintain an hg repo under your git repo. When (if) the time comes to shift to hg, use hg's convert extension.

Implementation information can be found here: ConvertExtensionImplementation...

The Convert extension converts repositories from other SCMs (or even Mercurial itself) into Mercurial repositories, with options for filtering and renaming. It can also be used to filter Mercurial repositories to get subsets of an existing one.

The current release supports the following repository types as sources:

CVS

Subversion

Git

Darcs

Monotone

Bazaar

GNU Arch

Mercurial

Perforce...


答:
One of agile tenets is Empower people and that is what you must follow if you want to go with Scrum. In other words Scrum / Agile is not for teams where team members are not able to take responsibility for their decisions => you should have some skilled / experienced team members to take care of your technical details.

As PO you can make constrains (lets call them global acceptance criteria or non functional requirements) and some of them can be technical. For example if your company has a strategy to have every application in Java you can make such a constraint at the beginning of the project but you cannot drive design / architecture of every single user story - it is team responsibility. Such global constraints should be defined upfront because they affect estimation of every user story.

Title: How can I provide guidance on technology choices through user stories?

Body:
I'm a project manager for a team of firmware engineers making the transition to adopting Scrum and I'm moving to support the team in a Product Owner role. We've just gone through Scrum training and are beginning a month of coaching which is going to be invaluable. Coming from a technical background I can already see the challenge of shifting my point of view from the solution domain to focusing on business value. For me it's very tempting to think of "how" to solve a problem. But I like the concept of user stories and defining vertical slices of functionality that give value to the customer and letting the team determine the "how".

Forgive me if this is a naive question, but as the PO how can I provide guidance on specific technical direction through user stories? My concern is that in some cases without guidance the team may head down the wrong path on key technical decisions.

As a simplistic example I might have a user story:

As a clinician I want the device to record information about the patient's treatment so that I can determine if the patient's therapy has been effective.

Now say time to market is critical and I want to fork out for an off-the-shelf file system stack to save time, what conveys that to the team? They might go off and start writing their own stack from scratch.

Is this sort of guidance provided through:

Conversations during sprint planning and backlog grooming? But if so, is it my place as the PO to even be suggesting how to solve a problem.

Acceptance criteria? I don't really like this, I have a bad feeling about making acceptance criteria so prescriptive that they specify how to solve a problem.

Constraints?

Thanks in advance. I could (and will) ask our Scrum coach but I won't be able to do that before Monday and this question has been really bugging me :)


答:
Rather than the binary bug chop, write tests in the form

Given...

When...

Expect...

To verify what you actually know to be true about the functioning of the app versus what you assume to be true.

Most IDEs make it easy to extract methods and to generate xUnit testing stubs. Make use of that.

Why not sprinkle debugs? Because after you are done, you will likely have to undo much of that work and delete a fair amount of those debugs. When you write tests, your debugging will aid in the prevention and detection of future bugs.


答:
There actually is a way - a real way, not an empty platitude - but you may not like it.

Have someone from the development team involved in the sales process.

Now obviously you need someone with good people skills, someone whom the sales people aren't going to be mortified about taking along for the ride. And this person needs to have a broad understanding of the kinds of work that you do. They don't need to be a code ninja, they just need a mild understanding of coding in general and your development process in particular, and be reasonably good at estimating work.

This is really a job for a business analyst or project manager. There's a reason these jobs pay so well at many companies; they combine two very important and distinct skill sets. If you don't have a real BA or PM but have a senior dev or architect with social skills, they can do it too.

You also need to provide clear guidelines for the sales people. Effectively, you (as in your dev team) are sending someone to negotiate on your behalf. If you don't give them any parameters, they'll just negotiate what seems good to them. That's why you always give them parameters.

Once you understand the project scope, work out how much time you would like to have for building, testing, scope changes, and so on, plus a certain amount of buffer, then give them that number along with an "authorized minimum" - the lowest they can possibly go before putting the project at grave risk. Expect them to undercut that number by a certain amount as well, so make your minimum a little higher than it really needs to be.

Rest assured that their management is doing the same thing. The sales manager does not want the sales associates selling unprofitable deals. They are walking into each negotiation with a range of numbers corresponding to the target profitability and minimum profitability.

You may not be their managers, but if you document all of this in writing before they even start to negotiate, then you're on much firmer ground with upper management when people start asking questions about why the project is behind schedule. But it's not just about CYA; the sales team honestly does not have any clue how long certain things will take, and you're doing them a favour by giving them comprehensive information.

One other thing: Don't expect the sales team to get your team involved just for the hell of it. You need buy-in from the sales manager and executives, too. It really shouldn't be too hard to get, if you approach it from a risk perspective. You don't want to sell failure, do you? Think of the cost to the company's reputation. Think of the cost of a lawsuit. Someone technical must be part of any negotiation before any deal can be signed.

And if you really, honestly cannot sell management on the idea, then might I suggest finding a new employer? Because yours may not be around much longer anyway.


问:
How do I validate the html/css and JS code outsourced to an external company.
We have outsourced the html and css design to an external company. We want to make sure the quality of code is good. What benchmarks can we set to achieve this.</p>

答:
Use lint tools:

csslint

htmllint

jshint

The source for css lint is also available at github and according to their docs, html lint should be available soon. The advantages of using the source are:

You can work offline

You can define your own lint rules

You can have your outsourcers integrate your rules into their pipeline to ensure they catch any obvious errors soon

Have a coding standard for both CSS and HTML and ensure that they're given to your outsourcers. Ensure that deviations from your standard are followed up on and the work rejected. Make sure that you follow this rigidly. As time goes on, one would hope that you get less errors, but the more you allow (especially early on), the more frequent (and worse) they can become.

OwnerDisplayName: Lakshmi


问:
Should interface names begin with an "I" prefix?
I have been reading "Clean Code" by Robert Martin to hopefully, become a better programmer.  While none of it so far has been really ground breaking it has made me think differently about the way I design applications and write code.

There is one part of the book that I not only don't agree with, but doesn't make sense to me, specifically in regards to interface naming conventions.  Here's the text, taken directly from the book.  I have bolded the aspect of this I find confusing and would like clarification on.

I prefer to leave interfaces unadorned. The preceding I, so common in today’s legacy wads, is a distraction at best and too much information at worst. I don’t want my users knowing that I’m handing them an interface.

Perhaps it is because I'm only a student, or maybe because I have never done any professional or team based programming but I would want the user to know it is an interface.  There's a big difference between implementing an interface and extending a class.

So, my question boils down to, "Why should we hide the fact that some part of the code is expecting an interface?"

Edit

In response to an answer:

If your type is an interface or a class is your business, not the business of someone using your code. So you shouldn't leak details of your code in this thrid party code.

Why should I not "leak" the details of whether a given type is an interface or a class to third-party code?  Isn't it important to the third-party developer using my code to know whether they will be implementing an interface or extending a class?  Are the differences simply not as important as I'm making them out to be in my mind?

答:
If you stop to think about it, you'll see that an interface really isn't semantically much different from an abstract class:

Both have methods and/or properties (behaviour);

Neither should have non-private fields (data);

Neither can be instantiated directly;

Deriving from one means implementing any abstract methods it has, unless the derived type is also abstract.

In fact, the most important distinctions between classes and interfaces are:

Interfaces cannot have private data;

Interface members cannot have access modifiers (all members are "public");

A class can implement multiple interfaces (as opposed to generally being able to inherit from only one base class).

Since the only particularly meaningful distinctions between classes and interfaces revolve around (a) private data and (b) type hierarchy - neither of which make the slightest bit of difference to a caller - it's generally not necessary to know if a type is an interface or a class. You certainly don't need the visual indication.

However, there are certain corner cases to be aware of. In particular, if you're using reflection, interception, dynamic proxies/mixins, bytecode weaving, code generation, or anything that involves messing directly with the environment's typing system or code itself - then it's very helpful and sometimes necessary to know right off the bat whether you're dealing with an interface or a class. You clearly don't want your code to mysteriously fail because you tried to add a class, rather than an interface, as a mixin.

For typical, vanilla, run-of-the-mill business logic code, though, the distinctions between abstract classes and interfaces do not need to be advertised because they'll never come into play.

All of this being said, I tend to prefix my C# interfaces with I anyway because that is the .NET convention used and advocated by Microsoft. And when I'm explaining coding conventions to a new developer, it's far less hassle to just use Microsoft's rules than to explain why we have our own "special" rules.


答:
HTTP is stateless, so there is actually no such thing as a non-realtime web app and therefore no reason you can't use node for everything.

That said, node is better suited for a particular type of application architecture. PHP is html files containing a bit of code. Node is code optionally containing a bit of html.

This means that if your app is standard html forms without any client side script, PHP will be easier. Node does have templating tools, but obviously not as mature as something like PHP.

If you have a lot of client side scripts and save the data with ajax, you end up with a static html client calling functions on the server. This is exactly what node is good at. While not the way CRUD apps are usually built, you can produce something pretty nice with the right framework.

Title: Is there a good reason to avoid node.js for non-realtime web apps?

Body:
I've seen a lot of talk about how awesome Node.js is for realtime web apps -- things that need sockets, Comet, AJAX-heavy communications, and so forth. I know that its event-driven, asynchronous, thread-driven model is also good for concurrency with low overhead.

I've also seen Node.js tutorials for more simple, 'traditional', non-realtime apps (e.g., the standard blog example, which seems to be the standard 'Hello World' for people learning app development). And I also know that node-static allows you to serve static assets.

My question is: is there any good reason to avoid Node.js for traditional web apps, like classifieds, forums, the aforementioned blog example, or the sort of CRUD apps you build for internal business applications? Just because it excels at all the funky realtime stuff, does that contraindicate it for more staid uses?

The only thing I can think of, off the bat, is the lack of mature libraries (although that's changing).

(The reason I'm asking is that I'm considering ditching PHP for Node.js, mostly to get over the impedance mismatch of switching between languages, but also so I can reuse validation code and whatnot. My superego admonishes me to choose the best tool for the job; however, I don't have a lot of time to learn fifteen languages and all their userland libraries just to have a comprehensive arsenal. It's also reassuring that Node.js might give me an easier optimisation path than PHP/Apache in the future when I have to start thinking about heavy traffic.)

[EDIT] Thanks for the answers so far, folks; I just want to see if anyone else will weigh in before I choose an answer. The answer from @Raynos kinda confirms what I'm thinking, and the links from the commenters provided good food for thought, but I want to see if anyone else has any Node-specific answers, like 'DON'T USE NODE FOR PROBLEM X'. (Besides high-CPU tasks; I know that already :-)


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

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

答:
“ Copy and paste is a design error. ”
   -- David Parnas

LastEditorDisplayName: Roger Pate


问:
Can someone find a job as a programmer without an education?
Interested in knowing from the more experienced ones if someone can find a job as a programmer without even a highschool degree. Consider the said person to be an average programmer. Would someone even consider giving him/her a chance on an interview ? The languages of interest would be python/php/java/c#

Please answer for your region/city/country only. No "go back to school" answers please.

答:
I think most places will give you a shot at an interview at least, and whether you get the job or not will be based on your interview.

We were recently trying to hire someone, and we didn't care what the application said. What we were interested in was Work Experience/Past Projects, Sample Code, and how the interview went. Its easy to get code online or to follow tutorials to create sample projects, but talking to someone generally identifies if they actually know their stuff or not.

Also as a side note, if you have no Programming-Related work experience, leave it off your resume. That's the one bit that would actually put someone in a negative light before the interview with me... if their previous experience was all something like working at McDonalds. If you don't have any programming-related work experience, list projects you have worked on in the past instead (personal, open source, etc).


问:
C++ skills higher than C skills?
I feel that the often seen C/C++ doesn't really describe my skills in my CV. So I'm planning to separate it into advanced C++ knowledge and mediocre C skills.

Do you think this is confusing for the reader? She could think: "C is a subset of C++, so what is this guy trying to tel me?" Well, what I'm trying to tell is: I have done several real world C++ projects while pure C projects where just a hobby thing. Do you agree that a skilled C++ programmer not necessarily is a qualified C guy or do you think that this switch is done easily?

答:
I liked your phrasing: "I have done several real world C++ projects while pure C projects where just a hobby thing"

So I'd just put it in CV jargon:

worked on several C++ products

a few side projects using C

It's better if you put numbers in place of "several" and "a few". No need to be exact, "over twenty" is a number for this purpose.

The "skill level" description is correct, but the "experience" description is correct and clear.

Title: C++ skills higher than C skills?


问:
Will Python developers find it easier to learn C (and vice versa)?
Since Python was written in the C programming language, does it mean that if I know C  I will learn and master Python faster than it would take me to learn it without prior knowledge of C?

Or will Python coders find it easier to learn C than programmers from other languages not related to C?

答: Languages built on others can operate in fundamentally different ways, introduce new concepts. Just because every operation in Python must be translatable to an operation in C doesn't mean that that operation is feasible or good practice in normal C. The time you expend learning C won't really help you with Python, relatively speaking.</p>


答: Python syntax is nothing like that of C. So having prior knowledge of C really has nothing to do with how well you will learn python. Just because under the hood there is C code doesn't mean that you will learn python any quicker because you know C. As a python programmer you are dealing with the syntax of python not C.</p>

Title: Will Python developers find it easier to learn C (and vice versa)?

Body:
Since Python was written in the C programming language, does it mean that if I know C  I will learn and master Python faster than it would take me to learn it without prior knowledge of C?

Or will Python coders find it easier to learn C than programmers from other languages not related to C?


答:
Make sure you specify in the contract what you will validate.

Browser support. Consider requiring that the code work in all the browsers that you require (not just Firefox or Chrome). This will go a long way to getting you something you can actually use. By far the most common problem is receiving code that works in one browser, and then when you try to actually deploy it, discover it doesn't work in any other browsers, and fixing it is very expensive.

Validate. You can require your service provider to provide validated code using various validation services. Google W3C HTML validator, and work out what version of HTML you will support. There are similar CSS validators. Neither guarantee quality-- but perhaps they will discourage some service providers from applying or doing a really bad job. At least it is a bar you can set

Hire an Independent Reviewer. If don't have the technical expertise, get someone on your side that can be part of the whole process in a very limited advisory role.

Demand Transparency and Early Delivery I like to try out vendors and test that early on. This means starting with a small project, seeing how they do. Request a small change to measure their response (communication, responsiveness, attitude, etc.). Get a independent party to review the work, and see how they react to the feedback. This will give you insights into how the relationship will play out long term.

Good luck.

Title: How do I validate the html/css and JS code outsourced to an external company.

Body: We have outsourced the html and css design to an external company. We want to make sure the quality of code is good. What benchmarks can we set to achieve this.</p>


答:
The reference implementation of Python, CPython was indeed written in C, but saying that Python is written in C is an oversimplification:

There are implementations written in other languages, like Jython (written in Java), IronPython (written in C#), PyPy (writen in Python), CLPython (written in Common Lisp), Psyco (also written in C), Stackless Python (written in C and Python) and Unladen Swallow (written in C++)

Although the CPython interpreter is written in C, it is possible to write modules for it in C++ or Cython (not to be confused with CPython), as well as C

What language a language's interpreter is written in is only important if you want to write modules / extensions to the interpreter itself, it has nothing to do with the language

Several languages (like Java, PHP, C# and others) are referred to as belonging to the C family, that has nothing to do with what language tools (compilers, interpreters) for said languages are written in but it means that they have very similar syntax to C. Python's syntax is very different from C, not only does it not belong to the C family, its actually quite far from it.

Apart from the CPython interpreter, the only other relation that Python has to C is that they are both multi-purpose, multi-paradigm programming languages.

Whichever one you choose to learn first will greatly help you learn the other one, and that's true for every programming language, as the one you learn first will introduce you to programming concepts and ways of thinking that are common in every language.

Python is generally regarded as a higher level language, whereas C as a lower level language, meaning that Python is closer to what we humans consider friendly and C closer to what the machine considers friendly, so Python is a little bit easier for beginners to start with.


答:
At my old job the two best developers were a guy with a BS in Math, MS in CompSci; both from top tier schools and a guy with a GED who spent six years in the USMC and dropped out of community college after six weeks to take a full time programming job.

The Marine was self-taught and absolutely tenacious. First one in, last one to leave.

They were equally productive but the grad student work about 2/3 of the hours of the Marine.

Title: Can someone find a job as a programmer without an education?

Body:
Interested in knowing from the more experienced ones if someone can find a job as a programmer without even a highschool degree. Consider the said person to be an average programmer. Would someone even consider giving him/her a chance on an interview ? The languages of interest would be python/php/java/c#

Please answer for your region/city/country only. No "go back to school" answers please.


问:
xpath vs DOM API
I just came up on xpath recently while writing a greasemonkey script and immediately fell in love. I haven't done any benchmarking yet (coming soon), but according to a couple sources that I read, xpath is faster than using the DOM API. After checking out the internals of a couple of libraries (Swizzle and jQuery), I noticed that neither use xpath, but use the DOM API.

My question is: Is there something here that I'm not seeing as to why these libraries haven't changed to use xpath (or were first written using xpath rather than the DOM API), or is it just that xpath just hasn't quite caught on yet?

答:
Apples to Oranges.

'XPath' is a language for querying.

'DOM API' is allows you to not only access the document, but also interact with it. Eg: Adding and deleting nodes.

As to brenchmarking, that would be slightly nonsensical. The first is a language specification, the second is an API. How do you benchmark a specification? If you benchmark an implementation of XPath you will get vastly different results even between implementations, yet alone trying to compare to other conventions.

Title: xpath vs DOM API


问:
Setting up Eclipse IDE for Python and PHP development
There are various versions of Eclipse IDE available at Eclipse Download. Since, I am not concerned with Java development, I downloaded the Eclipse Classic 3.7.1. Now, I want my IDE to be setup for Python and PHP development.

1) Have i downloaded the correct version ??

2) What tools should i download next.

NOTE : I haven't installed anything yet, just downloaded the classic version from Eclipse website.

答:
Eclipse 3.7.1 is the latest version, so it's fine. You'll also need:

PHP Development Tools and

PyDev

and of course you'll need some kind of PHP stack and a Python interpreter.


问:
What's your strongest opinion against functional programming?
Functional programming is one of the oldest programming paradigms. However it isn't used much in the industry compared to more popular paradigms. But it have largely been emphasized in academia.

What's your strongest opinion against functional programming?

答:
I'm not opposed to FP as a useful paradigm, but I'm opposed to it as the only paradigm available in a programming language.

It offers advantages in solving a lot of problems. However FP can, and has been, applied in procedural languages like C.