stevensanderson

> We could simply swap wallets

How would you prove to me that you don’t still have the key for your old wallet?

Having VS2022 crash is certainly not expected or normal. I appreciate it must be pretty frustrating. If there’s any way you can submit a VS Feedback item when that happens, or post repro steps to the dotnet/aspnetcore GitHub repo, we’d definitely want to investigate.

Or it shows most people answering surveys claim to be happier than they really are.

Release notes: https://github.com/aspnet/Blazor/releases/tag/0.1.0

Blog post and tutorial: https://blogs.msdn.microsoft.com/webdev/2018/03/22/get-start...

The CoreRT and Mono folks certainly do talk to each other.

As I understand, Mono is going to be moving forwards with WebAssembly much faster than CoreRT will do. Mono has officially committed to it already, whereas for CoreRT it was more of an exploratory spike.

Also it makes much more sense for Mono to be the .NET runtime for WebAssembly. Mono is already Microsoft's preferred production-grade .NET runtime for most client scenarios (iOS/Android native apps, Unity games) and is designed for that kind of portability. WebAssembly is another client platform like those.

Note that this is a simulated example, not one actually taken with a modulo camera (if such a thing has been built yet).

That image of Tintern Abbey comes from this 2011 web page: http://people.csail.mit.edu/sparis/publi/2011/siggraph/addit...

That's exactly where you are right now (and everywhere else).

Thanks for flagging this.

The version of the specs published to knockoutjs.com didn't match the final release. I've just updated them. Please let us know if anything is still failing, preferably at https://github.com/knockout/knockout/issues

No, that page is just info on behavior changes for people upgrading from KO 2.x.

We haven't published the official 3.0 announcement yet, but you can find an overview of what's new on my Release Candidate/Beta blog posts:

* http://blog.stevensanderson.com/2013/10/08/knockout-3-0-rele...

* http://blog.stevensanderson.com/2013/07/09/knockout-v2-3-0-r...

I wish this were true, but unfortunately not. Object.observe doesn't provide any 'read' notifications, so you wouldn't be able to detect dependencies like this does.

Would that be considered negative? In any case, KO is not a Microsoft project, and only one of the core team members (me) works for MS.

Anyway, many projects are built with KO, and its 3500+ watchers on GitHub suggests it's something like 7 times as widely used as one of the libraries in the article, so it's perhaps inaccurate to say that nobody considers it!

Looks awesome - nice work!

I can so easily relate to this. Although I deal with only a fraction of the GitHub traffic that Jeremy does, it's still demoralising at times, and dominates the effort I spend on OSS. It's the equivalent of every widget owner having the CEO's home number, and it being culturally normal to call to discuss any problem or even idea for minor tweak.

One possibility I've wondered about is making the GitHub issues list read-only, except for project maintainers. Then bug reports and feature requests would go initially only to the project's forum or IRC channel, which has much less maintenance cost, because threads or conversations don't need to be "closed". If they attract enough attention (because they describe a painful bug, or a really good idea), then a project maintainer is likely to notice and choose to file an issue.

I was going to try it out, but once you've registered, you have to raise a support ticket to ask them to put a free trial on your account.

> Step 2 - Experience a Free Trial After registering your MacinCloud website account, please log in and create a new Support Ticket under Help > Support > New Support Ticket. Click New Support Ticket -> MacinCloud Trial -> Sales, and request for a trial. Please attach a note and let us know if you have any specific needs.

Um, no, sorry. I don't have that much patience. Honestly this could be a great service for Windows-based web developers who just need a few hours on a Mac now and then for testing, but the signup process needs to be instant.

IIS isn't blocking any of its threads once it's handed a request off to Node.js. IIS receives the incoming connection and proxies it via a named pipe into the Node.exe process, so the performance and capacity is much the same as if the requests went directly to Node.

I also reproduced something like this.

On "Step 1: Add Friends", it showed people who I actually know (presumably who have my phone number, since that's the only info I gave that actually relates to me)

On "Step 3: Profile Information", it offered many more people, most of whom I don't actually know (presumably friends of the people from step 1)

Note that to trigger the mobile-number-confirmation request, you may need to enter dubious-looking profile information. In my case, I entered a name like "Blaah Blahh", with a throwaway email address from www.mailinator.com. If your fake name is too realistic, it won't necessarily trigger the security check.

I do have the same mobile number on my primary account, so it's possible they found me that way. But either way, it's notable that in step 1 they managed to show just the people who I would expect actually do keep track of my phone number.

Oh, that kind of databinding. That doesn't really bear any relation to what knockout does :)

No objection to your general comments, but just to clarify, knockout.js is a regular open source community project, not an MS product. Also, do try it - you might find this approach to binding to be much more compelling in a dynamic world (i.e., JavaScript).

Knockout focuses more on the front-end - helping you make a sophisticated UI that responds to view model changes using declarative bindings. It isn't as opinionated as backbone about how you should load and save data.

Both approaches are valid; either could be preferable depending on whether you're focusing most on the UI or on the data.

It can do in cases where you find that more convenient. Whenever you prefer to move logic into your view model and just reference it, you can do so. It's intended to be flexible.

The evaling is a robust way to parse the JSON-like binding syntax at the full speed of the browser's native code. Much faster than implementing the parsing in JavaScript.

Think of the bindings as data, not as procedural code.

It's so much more convenient to do it this way (avoiding having to figure out where each bit of behaviour comes from), especially when you're generating UI from within templates.

See http://knockoutjs.com/documentation/observables.html#how_dep...

Knockout is meant to enable the whole MVVM pattern, and supports it with:

* Declarative binding syntax (a very simple way to link model properties/functions to DOM elements without writing manual "render" functions or event handlers) * Automatic dependency tracking (so you can have arbitrary nested chains of computed properties that combine multiple observables, and so KO can work out on its own exactly which part of your UI to refresh after any given model change).

The templating stuff is a bit more baked in with KO too. Backbone, on the other hand, does more of the JSON data access stuff natively, whereas KO assumes you'll use normal jQuery Ajax for that.

(Disclaimer: I don't know backbone.js well, and I created Knockout, so you may want to make your own comparison.)