Anecdote: I have an Azure account with a monthly spend of around $100-200 (so, a very small customer). I ran into an issue with Active Directory B2C a couple of years back. I reached out - despite not having a support plan - and ended up with a Microsoft Engineer sharing my screen and helping me fix the issue.
Being remote certainly helped Australia, but I think this "island" line is a massive cop-out.
Mainland USA only has land borders with Canada and Mexico, right? Do you believe that if those borders were impermeable that they'd have COVID beaten? And the only reason the outbreak there is so large is due to cases sneaking in from Mexico and Canada every day? In reality, the vast vast majority of USA's COVID cases came from the exact same place as the majority of Australia's COVID cases - people flying in, and community transmission.
Yes, Australia has had a few advantages when fighting COVID. But hand-waving Australia's success away as "it's an island!" just serves to ignore the lessons that could be learned from Australia's response.
I'm not sure what you are trying to say here. The party that pushed for these news laws is the same party that has been opposing real action on climate change for years.
Of those 20 years you mentioned, the party we're discussing has been in power for around 14 of them - and the 6 years preceding that. I'd say the party that has been in power for over 75% of the last 25 years - and has actively campaigned against acting to reduce emissions - is somewhat responsible.
But what I don't understand is the relevance of climate change to the topic at hand: the assistance and access legislation harming Australian tech companies. And I'm still not sure what your original point was ("Australia's abysmal record on climate change affords it no sympathy"). Were you saying saying that Australia's tech industry deserves to be destroyed because a slim majority of the country keeps voting for a party that is, among other things, hesitant to act to reduce emissions?
Well, you literally said that it was useless and that you gave up before you began. Given that, I'd say that revelation's comment was pretty useful - explaining how you could quickly and easily get up and running with .NET. Perhaps you could tone down the hyperbole next time?
Well, if you had actually read the page, you'd see it also supports PostgreSQL and MySQL. In addition, it's open source so you could implement your own data store. Finally, I don't see why SQL Server is somehow irrelevant to the 'Hacker News crowd'; it's a very good RDBMS.
Really? We haven't had any problems with our .NET Core projects (a few web apps running on core and a bunch of libraries targeting core). In addition, ASP.NET Core (on .NET core) has been a great stack so far (using it since beta5); I feel very productive with it as well as enjoying the development experience. Why do people need to get fired for this? It doesn't seem like it will be hard to move from project.json back to (a new and improved) csproj.
Yes, Really, and I am sure there are some people who have had no problems. That doesn't invalidate the countless hours I spent making this dreadful system work. Did you put it on your build server without installing Visual Studio on it?
Our build server (TeamCity) does not have VS installed.
I can actually tell you the exact software installed on the build server:
1.) Window Server 2016 (Base OS)
2.) SQL Server 2016 Express with LocalDB only (used for longer integration tests that need to validate migrations)
3.) DotNetCore.1.0.1-SDK.1.0.0.Preview2-003133-x64.exe (.NET core SDK 1.0.1 download from https://www.microsoft.com/net/download)
4.) BuildTools_Full.exe ("Microsoft Build Tools 2015 Update 3" https://www.visualstudio.com/downloads/#d-build-tools). If you have this, then you don't need the full VS install
5.) NodeJs (for running webpack as part of 'dotnet publish')
6.) TeamCity and Octopus Deploy agents
>Did you put it on your build server without installing Visual Studio on it?
Huh?
`docker run microsoft/dotnet`. Took about 2 seconds to get it running on my Jenkins build server. In reality, it took literally no effort. My entire full stack app requires `make` and `docker` to build and nothing else. The backend is an AspNetCore API.
Everyone's been having problems with them, how can you have had none?
They seem to massively change something every 10 minutes.
I also don't get the 'massively productive' comment, in essence very little has changed since, hell even MVC 3, apart from the obsession with DI and a load of packages now don't work. If you weren't 'massively productive' before, you were probably doing something wrong. They just moved a couple of things around and now insist you use npm/bower/whatever hotness they latch onto next week instead of nuget. I'm sure we'll have another blog post about them ditching support for anything but yarn next week.
And how long before they change their minds about how controllers work again, it's been like 4 times in the last 5 years now. First MVC controllers, then Web API, then Web API 2, then OData, then .Net Core, all very similar but slightly different with slightly different ways to register them at startup and slightly different things available on the context. Apart from the utter madness that is OData, great for data tables, bloody awful for everything else.
It's getting almost as bad as javascript churn but it's one company so it doesn't make any sense.
It changed during the pre-1.0 era when the team were very clear about the potential for changes. The big changes were made with plenty of notice and short term backwards compatibility baked in. MVC 5 is still there and still being supported - deliberately choosing to use Core should have been a calculated decision based on what you needed and appetite for risk. If there's a bad influence from the world of JS it seems much more around devs deciding to go into production with "the new hotness".
Moving to npm/bower for front end stuff makes perfect sense, NuGet is a horrible way to deliver client side code, wasn't supported by the majority of library producers and was unknown by anyone who didn't have a .Net background.
I expected changes at the beta stage. I did not expect the major changes between RC1 and RC2. Try writing a book against a moving target! :)
I think all the changes now are due to that late switch of direction. RC2 went straight to 1.0 but it was a major change and should probably have had some more beta/RC releases.
It's not just change. It's difficult to make it work for a single version. It was difficult back when the build tools were a handful of powershell scripts. It was difficult when they moved to the dotnet tooling.
Microsoft shouldn't push out an RTM product and call the broken bits "Preview" to absolve themselves of the responsibility to deliver a reliable product.
I was evangelical about .NET Core. I stuck with it for years. I stuck with it when Damian admitted that he "doesn't build web apps". I stuck with it during the Release Candidates. It's only when they pushed this out the door and called it RTM that the penny dropped and I accepted the project had been mismanaged.
They announced all of this before .NET Core went RTM. Not only that, the tooling was never made RTM (still in preview). If you jumped on the bandwagon that early then you had all of this information and knew what was coming.
You should just wait until both the framework and tooling are RTM if that's the stability you need - the framework is already great but if you need the tooling then wait until it's ready.
Why complain if you understood the status and assumed the risk?
If you knew anything of the traditional release history for Microsoft you wouldn't have commented. All your post demonstrates is total ignorance of the context or history.
It was previously totally fine to use RCs for the last decade, probably way before that too, but I only have experience from then. RC in MS speak meant "pretty much finished, API won't change unless we find something desperately wrong".
Then it suddenly means basically pre-alpha, "anything can change, massively, between RC versions".
> They seem to massively change something every 10 minutes.
> in essence very little has changed since
?
The one thing Microsoft is great at is compatibility. Your existing projects can keep using the older frameworks and they're still supported and will run just fine. What is the issue? If it's about learning the new changes, then it's probably best to wait until everything (framework + tooling) are final so you only have to learn once.
I honestly have no idea what point you're trying to make.
The problem is that it's hard to understand what does what and how it does it. Things in even the same project behave differently. They introduce massive architectural changes and then abandon them. Searching for something in SO now is a crap shoot, which slightly in correct answer will you get because the asp.net team changed their mind again?
And you can have all these things running in one project, all acting differently.
I work with clients on MVC 3,4,5, with parts in web API 1 and 2 and parts in odata.
And they all behave differently.
For example, and this is just one of many, a JSON date from an MVC controller is 'Date(173737273)', from a web API it's '2016-12-26 23:00:00.0000', from an OData controller it's '2016-12-26 23:00:00.0000Z'. That Z changes behaviour btw and makes the terrible assumption your date is in the same TZ as your server.
All of them are parsed different and will return different dates in javascript.
Perth is actually doing an excellent job shaking off the 'dullsville' tag. A lot of restrictions have eased and the city is flourishing as a result. Hopefully even more so in the next few years with projects such as Elizabeth Quay and the Northbridge City Link finishing up.
Hell, Perth is doing everything it can to booze itself up .. it is after all, one of the first Australian cities to just let the Casino mafia take over.
In the .NET world we have Dapper (https://github.com/StackExchange/dapper-dot-net), which lets us write queries in plain old SQL. It's a very useful little library. I believe StackOverflow use it for their data access.
Example:
var posts = connection.Query<Post>("select * from posts where user_id = @UserId", param: new { UserId = 1 });
