LOL. I've spent a lot of time trying to be wowed by microseconds. I've not succeeded.

There's a lot of waffle in the responses but the truth is as it is for most things... It depends on what you're developing. Some people have alluded to this. I have worked on projects that have used code first effectively. No performance bottlenecks, easy deployments, very neat code. Easy to follow and all in one place. If you have a fairly simple schema to create, code first is not going to be a problem. If you have a more complex schema, then you may have to evaluate it a bit more. I have worked on projects that code the DB first. This gives you the most control and is the more consisitent approach when writing stored procedures, triggers and other object types. If using Visual Studio (assuming as you're using EF) and if you're also using SQL Server then Visual Studio DB projects are great for modelling databases and doing quick and easy deployments. ORMs are great but use with a little caution as you may introduce unnecessary overheads. In summary, to answer your question more directly, yes code first is used for real applicstions/projects. On the question of whether to aspire to it, I do not believe it should be considered a standard or any sort of evolution of development - you would use it based on the merits for your application.

You can't be serious? That's both hilarious and infuriating.

As is often the case, there are reasons for and against using an ORM. Sadly, there are many extremists in both camps. I've worked on projects which do with and without ORMs. Examples of reasons for (not exhaustive): 1. Avoid hardcoding SQL in your OO code 2. Makes unit testing easy in. Net 3. Repository out of the box 4. Can be very quick to setup Examples of reasons against (not exhaustive): 1. Lots of business logic in the database layer 2. Difficult performance targets 3. Limited system resources (memory) 4. Tiny database - not worth the overhead Then the question becomes which ORM. Nhibernate comes from the Java world so you'd automatically be weary however, used right, it's fine. As someone on here already mentioned, you can still write direct SQL and call sprocs using it and just use nhibernate as the wrapper. EF wasn't great in it's infancy and didn't play too well/at a with non-SQL servers but it's a big boy now and is much better. I'd use it over nhibernate if you can get the drivers for the database. To ORM or not to ORM is not the question. The question is whether it's right for your project or more specifically, if it's right for your database/app model. To rebut what someone said earlier, I'd argue that you should have a good knowledge of writing SQL and investigating performance whichever route you go. I will not however that what you hit a problem with an ORM, particularly nhibernate which I've used in the past, you could be stuck for ages as the docs aren't great and there used to be lots of bugs but to be honest, this shouldn't happen so much nowadays unless you're trying to get super fancy. Still I haven't used nhibernate for 5 years. Good luck

I have the Surface Pro 4 with one of these keyboards/covers in teal. 1 year in and I'm still happy with it. Almost as clean as the day I got it. Fairly easy to wipe clean although you feel odd doing it.

I recently bought a Synology and I agree the web interface is excellent.