We plan on moving to it sometime this year, from "old" dotnet. The timings is unclear because it depends on a few factors both on our side and from Microsoft/the community. For example we are on trend of using Entity Framework less in favor of dapper, so when the bits we are still using are fully supported by entity framework core that block will be cleared. Other big dependencies like a posgresql driver are already ready to go IMO. Tooling still isn't 100% ready in visual studio 2017 with web deployment being a key problem.
My advice would be to only use it now if you are starting from scratch and you have no business goals in the next 6 months (you are building an MVP and can take the hit of some random bugs in production). I know that at least one startup is using it for critical services, but they are also committed to fixing the dotnet core source code when they run into a problem and I believe are part of the reason for the good pref of kestrel (new web server), I think unless you are willing to do that you should wait a bit longer.
Separate the declaration to 3 lines because the 2nd and the 3rd declarations depend on each other. Keeping them on the same line makes the reader think this is a simply declarative code but in fact it's the opposite.
Avoid using the slice shift combo but use slice with a start of 1 plus direct index access to the arguments[0] to get the first argument. this way i'm not mutating the args array and that makes the code easier to follow.
Rename the object variable to '_this'. Giving the reader a hint as to what it is used for.
And of course if this is actually to be used in production I assume it will be wrapped inside a check to see if the bind function is already defined.
The specs are the part I found most interesting.
1) First the specs say 3 images, then they say 2. if you are dealing with a manager that can change the specs like that you might want to over engineer just a bit to cover 'arbitrary number of images'. yes I know this is probable just an error by the writer of the article, but it demonstrates something that happens in the wild.
2) Communication is the missing piece in this story. when a developer is given a task they should ask questions about future requirements. "Is it always going to be 3 images?", "will the images always grow by the same ratio?" and so on. the way to not solve imaginary problems is to talk with the stakeholders.
I took a look at the products while visiting the site. Where would one go to find laptops that are preinstalled with free software but are also powerful? high-end cpu and the like.
No I'm talking about the version numbers themselves, things like:
1.0.0-preview2-final
I will not take a working(and money-making) code base and migrate it to a platform where that is the version I need to use.
As for project.json. I actually liked using JSON over XML, but it's a personal preference thing, can't really make a case that it's better.
I recently built a web app with the new dotnet core . the changes were not so bad, I even found that the docs were nicer than the ones you find for the "old" asp.
After having to configure camalCase for json a couple of times I like the new default.
But migrating an existing app at this point is out of the question, when I no longer need to have nugget packages with rc in the version name we might do it.
I have a different understanding, it's not resistance for resistance sake, it's the willingness to dissent when you disagree. The first thing that pop to my mind is a book by Christopher Hitchens called "Letters to a Young Contrarian". While he enjoyed arguments he did not argue for argument sake for a position he did not hold.
I disagree with his position on that issue (var at the top) but somehow I'm not hurt by him calling "my" position stupid. People are allowed to have strong opinions on things, especially if they have spent a great deal of time studying them. And I do want to hear his opinion spoken loud and clear because the conviction is a signal that I should not ignore the opinion lightly.
If you did that without first asking about what Ecmascript version you should support I would prompt the question myself, and if you didn't find a different way then I would consider it a very bad sign.
Every time I start getting into f# the Roslyn team comes out with new features taken from FP (tuples, local functions, pattern matching) and narrows the gap. So I postpone the move from c# to f# to a later date .
The things I know are never coming to c# (like data providers) are not important to me.
So for me c# is the greatest block against f# adoption.
bug report: In the article search type in some non English chars like : "אאא". JavaScript exception then breaks the search for good, this must be the first search you make.