Based on the information it seems as through this is for queues and topics only. Does it also include relays? If so, are the benefits the same? We mainly use relays as our application requires synchronous communication, which the relay facilitates.
What is the relationship between the groups as described here with other groups of users in the various parts of O365...Yammer groups, Sharepoint groups, Groups as defined on the Admin area of O365, etc. None of these seem to be the same thing or synchronized in any way (as best I can tell using the software today). It's very confusing -- hopefully you can start combining these things together to have one single way of grouping users together for the use cases across the apps and services within O365.
WPF via out of band NuGet packages is a great move! Seeing what it did for ASP.NET or especially EF, I can only see this being a good thing, especially if the investments aren't split between the "in-box" WPF and the NuGet package.
Although it does seem like WPF may never be truly cross-platform, it does seem like there is a good middle ground. Even if it remains Windows-only, what are the chances that it could become open source and sit on top of .NET Core? I ask because I have a solution that includes both ASP.NET MVC apps that I would like to update to ASP.NET 5 on .NET Core, plus WPF apps and Windows Services. I don't really have a need to run my app on *nix, but the other benefits of .NET Core are huge -- not having to ask each of our customers to install .NET framework updates would simplify so much.
I know I can use PCLs to share code between .NET Core-based projects and full framework-based projects, but frankly that should be a transient workaround. Now that WPF has taken the first step of moving to NuGet, getting it and its dependencies included in (or at least, compatible with) .NET Core should be a priority once the current crop of features have been addressed.
It's great to hear you are looking to build out this scenario. In a topology with multiple shards (hopefully) sharing the same schema, ideally most queries would be contained within each shard. However, in some cases a query spanning shards or relating together data between a shard and a common shared database (containing global data) is necessary. That's somewhat painful today. To the degree realistically possible, not having to write application-tier code to manually handle what most would consider a data tier concern would certainly make the Elastic Scale solution a lot more compelling.
For what it's worth, the other "pain point" of Elastic Scale is schema management. My hope is that existing solutions (SSDT, EF migrations, etc.) can gain "awareness" of Elastic Scale, and enhanced to support cross-shard schema changes. After all, every time "yet another schema management tool" (YASMT) is developed, a higher power sheds a tear!
Thanks for the update. I am glad to see you are taking a look at your social media strategy -- it's always a fantastic plan B when something like the service dashboard itself goes down. Even more, it's a great way to address specific questions not covered by service dashboard updates; I hope the new policy will permit this type of customer interaction as it makes sense.
Thanks @SQLScott! I really think having great tooling for SQL Azure's new Elastic Scale will be important for its success -- and personally I think SSDT makes sense as one of the ways to deliver this, especially for those of us who can't/don't use EF migrations; why create yet another schema management workflow! SSDT = good stuff.
We use database projects to manage our database schema for our Azure-based SaaS application. Our app is growing and we will soon need to shard. With the new sharding strategy (replacing federations), I wonder if the SSDT can be used to manage schemas across many databases. Is it possible to publish a schema change to a group of databases? I'm sure there are some challenges around this, but it would seem to be that some measures could be taken to keep things consistent -- e.g. validating as much of the schema change up-front against all shardlets before actually publishing the changes to each.
SSDT is such a fantastic way of managing our schema within our SDLC. It would be a real shame to have to manage this stuff manually once we begin sharding.
This was a *great* talk! I would like to have seen a little more explanation of how the activation functions work and what actually happens during training. Still, this presentation was WORLDS above a machine learning class I took in grad school, and I hope we continue to see more of this type of content at future conferences.
I still remember my grad school professor launching into content 5-10 minutes into the start of the course with a slide full of various symbols and terms, without any explanation of what they meant. Like you said, when so many different terms and symbols are used to represent the same concept (or even multiple symbols used to represent the same concept), learning and understanding this stuff is extremely difficult. We didn't even get any real-world examples. As you allude to, as a math-oriented researcher, the professor felt examples, code and practical considerations infringed on his beautiful theory! The best part was when mid-semester he announced that we were entering the "theoretical" part of the course (all I remember was trying to do proofs surrounding the kernel trick).
Bottom line: as you might imagine, as someone interested in Actually Building Stuff That Works, I can't express how much I appreciate a great explanation of some of these concepts. More, please!
Fantastic news. This has been a major issue for the development team to which I belong, so we are very much looking forward to this.
It sounds like this supports full "server" .NET, the client profile, the metro profile, Silverlight, phone, and XBox. There's at least one other .NET-based platform that doesn't seem to have received much love recently (but got a really quick mention in this video): .NET Compact. The company I work for has TONS (as in many, many thousands) of rugged mobile devices that run Windows Mobile 5 and more recently, Windows Embedded Handheld 6.5. These devices have to last for many, many years (upwards of 7). But the .NET version is still stuck at 3.5, and the development tools still stuck at VS2008.
Given that Windows Mobile is still supported and sold on new devices today, and that Windows Embedded Handheld still seems to be a current, supported platform, I would hope there are plans in place to bring .NET Compact to a current level (v4.0 or even v4.5), to support rugged device development in Visual Studio 11, and to add support for .NET Compact to the Portable Library Tools. We would love to share code between our ASP.NET apps, Silverlight apps, and .NET Compact apps but we can't due to lack of support in VS2010, and the lack of support in Portable Library Tools.
But still -- overall great news and great progress in the right direction!
OK -- fun awkward pauses aside, YES, the Portable Library Tools would be incredibly useful. And YES YES YES this functionality needs to come standard as part of Visual Studio! It is also very closely related to a talk given at this past PDC by Shawn Burke entitled "3-Screen Coding".
At my job, we have a custom framework library that we are trying to make work for: - An ASP.NET web service - A Silverlight app - A (gasp!) .NET Compact app for rugged data collection devices that will never ever run Windows Phone 7, but rather Windows Mobile 5/6.x/Windows Embedded Handheld!
Having a tool that could enable us to easily build common library components for all these environments would be beyond useful for teams that do development across many types of platforms and devices. I really hope Shawn Burke and the guys making the Portable Library Tools are talking because their goals are very closely aligned.
PS: Of course, .NET Compact and smartphone development first needs to be supported by VS2010 *at all*!! Get going on that, Microsoft!