Marcel de Vries, Technology Manager and Microsoft MVP, InfoSupport
I have always enjoyed Marcel's (the Dutch guy as he slides humorously show) sessions and am looking forward to getting some more information on SingnalR in ASP.NET. Great presenters (which honestly all #live360 presenters I've covered are) can combine knowledge, content, and even humor to make those attending have a much better understanding on a topic in just 75 minutes. Marcel is certainly in this category.
Before we get into SingnalR, we need to explore the current push/pull techniques we have. The 1st are web sockets, but they are only partially supported in browsers (still in W3C draft). Server side events (also a W3C draft) are another method that requires the client to have an extra channel for the data to be sent. The proxies also need to understand the content-type:text/event-stream. There is also 'long polling' which is really a fake push/pull method that responds to POSTs when the server has new information to send to the clients.
SignalR allows us to have real-time ability in our web application while extracting away the low level complexities of making the work required occur. It is a part of the ASP.NET web stack. The net result is a super simple and easy to use tool to get real-time information for things like dashboards, collaborations, messaging, or any other type of data that would normally require a Post back to the server or a page refresh. It's a great option right now that has strengths in places where the other frameworks and methods have weaknesses, yet sits atop all of these protocols to make the communication occur. It was advised to use .NET 4.5 because of the support for web sockets which is probably the best method if supported, but SignalR will fall back on the other methods when needed for scenarios like using older browsers (i.e. IE8). You may also dictate via configuration which protocols are allowed if needed. SingnalR does support web sockets, server events, long polling and forever frame.
The persistence connection in SignalR is the base class for our own connection class with overridable methods like 'OnConnected', 'OnReceived', and 'OnDisconnected'. To begin make sure to pull in the SignalR components from NuGet. I love the presenters that are able to articulate new technology with simple examples. Sure we will take it up a few notches in the real world, but if you are trying to sell (I use the word loosely) the technology, show me how easy it is to use. The example Marcel used was a vanilla web app doing chat/messaging. There were literally a few HTML controls, a little jQuery, a few lines of code in C#, and the example was up and running. The C# code was 1 line of code in the event to handle the message. As much as I use ASP.NET I'm amazed I have not yet had a use case for SignalR (I've used long polling in the past). Entry point pain: Low. Gain in user experience: High.
In SignalR 'Hubs' let you provide a semantic API between the client and server. SignalR creates a proxy between the 2 parties. The hub provides dispatch calls to filter clients using Clients.All, Client.Others, and Clients.Caller. You can use the context to read information about the call which seems quite useful and provides ConnectionID, headers, cookies, user, etc.. There is also 'Group' ability to allow arrangement of clients for communication needs. The hub can be set up in the $dcoument.Ready() function, and wire it up to the server proxy method.
Another informal poll was taken attached to a humorous story. Marcel tried to order a cake for his father's birthday recently and when he went to check out there was no 'Buy' button. He had to use Chrome for the site to work :P Oddly my experience has been the opposite. I typically use IE for shopping, knowing many still develop against it by default knowing it's wide adoption for the general public.
How many people are using IE all day long: 40%
How many are using Chrome: 55%
How many are using Firefox: 5%
How many are doing Windows Phone development: 2 people (Marcel: "Wow so many")
How many are doing WinRT: 2 people (Marcel: "Wow Microsoft is really moving along with that")
Ok what I found interesting was the use of other platforms for using SingalR: WinRT, WPF, Android, iOS through ViewModels to the different clients. Azure websites also support SignalR, so connecting a few dots with earlier sessions as well. He demonstrated an example using WinPhone, Android, and a local client using shape movement. A simple orange box was drawn and as he moved it around, the movement was shown identically on the remote device (actually a local emulator). He leveraged Azure in the middle to pass the data between.
Building Data-Driven Mobile Web Apps with ASP.NET MVC and jQuery Mobile
Rachel Appel, Appel Consulting
I have been following Rachel for years on Twitter, so it's finally nice to meet her in person and hear one of her sessions. I had the opportunity to eat lunch with her today and she is a really cool person too! I love her 'Sweet 127.0.0.1 Chicago' on her opening slide :D We engineers are so creative.
She began by going through the overview of ASP.NET MVC and its architecture. I actually think this is quit useful even for some seasoned MVC developers because I believe there are a lot of anti-patterns that exist even in MVC. It's always nice to have a refresher and speak to the purpose of the different components.
There was another good conversation surrounding Entity Framework and a code first approach. It's interesting to hear the preface that "if there is no DBA, or the DBA isn't DBAing this database" then as developers we are more comfortable in code and can have the code create our database. I still have a tad bit of heart burn over the following syntax (which is actually a toned down version of what I really am speaking to):
[Key]
public int ID {get; set;}
Now the above only has the [Key] attribute, but attributes for the SQL type, length, and other constrains can be added as well. I suppose I'm in a limited number that doesn't like SQL notations bleeding over into my code. Probably no more than a DBA would like it if I could place C# code in my stored procedures. I suppose if I have a very straight forward object model that will map well to a simple structure eventually in the database, I could go with the code 1st approach.
The DBContext class is a fancy 'connection' class where we can wire up our different models that are going to work with the database. We then use 'DBSet' with our collections (remember to make 'virtual' if doing navigation properties) to get it wired up. To connect all the dots we initialize the EF classes in Global.asax (for ASP.NET).
One convention in MVC is using a naming pattern to align the DBContext class to the web.config connection as long as the names are the same. This was we can switch between contexts by initializing the class needed at runtime.
A quick review was displayed on MVC scaffolding. To this date features like this are the helpers that can assist those still doing web forms and old ADO.NET calls and help provide a smooth transition to ASP.NET MVC and Entity Framework. Since EF is Microsoft's flagship ORM there is a close relationship to MVC and the ability to rapidly create data driven MVC applications is right there for developers.
One interesting thing I had not know upon reviewing the different view engines is that there is a 'Web Forms Controls' engine. This would create a style similar to web forms but is frowned upon because it's not really the MVC way of doing things (and I agree). However if needed it does exist. Most today are using the Razor View engine and the HTML Helpers. HTML Helpers are kind of like server controls without all of the view state and bloating. The similarity is that the Helpers are there to more quickly create controls in the View without doing it all from scratch.
She did a GREAT job of explaining the testability of Controllers in MVC. In web forms it is really difficult to hook into an entire page and it's event cycle to test it using unit testing. In MVC we can easily just instantiate a Controller instance and test it. Then we can have a complete suite of tests surrounding our controllers. If you are using a more advanced pattern where services are injected into your controller, you can mock up the service and still test the Controller's functionality. MVC in it's raw form is superior to web forms from the testabilty aspect.
Model binding in MVC uses convention to automatically map form data to our models when asking for the object in the parameter list of the Controller. This is another one of my favorite features in MVC. Remember the days of manually mapping form control data back to hydrate objects? The ViewModel or Model used in the Controller POST method combined with model binding delivers a fully hydrated object upon being called.
jQuery mobile is built atop the jQuery framework with support for HTML5 and touch bringin us into the modern era of development. With very change we can get a mobile version of our application up and running quickly. After downloading jQuery mobile, new JS scripts and CSS will be added to the solution. Go to _Layout.cshtml (like a master page from the web forms days), add the script references, and begin to use the data-* (HTML5) attributes to denote mobile in containers and wrappers.
You will get a Responsive UI now as jQuery goes through and applies the styles to make the page have mobile attributes (like touch enabled). There is no need to create separate Views for mobile either as the data-* attributes will add the CSS and JS needed for mobile, but is unobtrusive to your existing full blown web application. The CSS is really whats making the mobile aspect work, and the jQuery docs have all the information on the data-* attributes.
Side note - I love the quote 'Script Olympics' that Rachel termed for what is occurring in Solution Explorer (VS.NET IDE) with the massive amounts of scripts being automatically added in projects today. The alternative is to point to the CDN which are online versions of the scripts. Just keep in mind, that pointing to a CDN hosted script is not a good idea if internet access is not available for your particular application (i.e. building an intranet application behind 4 walls).
This session did have some review for me, but she prefaced that it would be (review) on some of the topics depending on one's experience. One area I feel I have a decent radar for is those that know how to articulate a topic or set of topics well. If one had never used MVC or EF, Rachel's style of delivery and presentation was second to none. She did a fantastic job of delivering content from the ground up in a simple and easy to understand way.
Anyone hesitant to use MVC or EF before the session has no excuse to not go home and begin building apps immediately. I look forward to hearing her speak again in the future!
Maximizing Entity Framework 6 in Your Web Projects
Adam Tuliper, Technical Evangelist, Microsoft
I'm a big fan of Entity Framework so this session is right up my alley. As usual we start off speaking to code 1st vs. database 1st conventions in EF. Adam prefers code 1st as he does not need a designer view. However, with the productivity tools, you can still engineer the visual design of your code 1st approach. This way if you need a visual you can still have it. This latter feature helps bridge the gap at least from a visual design standpoint which is nice wanting to try code 1st but still want a diagram.
Sometimes we need the ability to be able to see the queries that are generated by EF. Glimpse and Beyond Compare are (2) tools that help us inspect the queries. There is of course the SQL Profiler but it's a bit too disconnected and raw for our needs. These tools run a bit more closely to the application to inspect the EF traffic.
One cool thing I saw in the NuGet package manner that I did not know existed was intellisense. To activate Glimpse add in /glimpse.axd after the URL to get the display in the bottom half of the browser.The queries will be in the 'SQL' tab. In the 'Session' tab you can see the last several sessions to get a history. Click on the 'Model Binding' tab to see how the values are mapping to the model object being posted. Needles to say there is a ton of functionality.
You can also have multiple contexts per DB. 1 option is multiple EF apps per database allowing multiple devs to you the same DB. Multiple contexts per project DB all separation of intent and multiple devs to use the same DB. By using the .HasDefaultSchema() you can dicate which schema the entities have applied to them.
In ASP.NET there is a limited number of threads in the thread pool. If they are all used, subsequent requests must wait until threads are freed up to continue processing. When using 'Async' this limitation is not applied. Async queries hand off processing to a separate system thread. The reason for using Async would be for long running queries.
In EF6 there is now support for stored procedures via a code 1st approach. We could always run a stored proc manually via context.Database.SqlQuery<T>("dbo.my_stored_proc) but there were no annotations for using them. Now there is stored procedure / script support for Insert / Update / Delete only. Why no Select you might ask? Then what's the point of using the power of EF and an ORM. You are supposed to leverage the ORM for data pulls and not be doing it manually. As Adam states: "So if you love stored procedures or you have a DBA that's stronger than you, then this is an option."
We next delved into architecture surrounding an EF implementation. Adam reiterates there is no 1 single solution in practice. Some of the better practices though are using a combination of POCOs and ViewModels. There is no reason to send a huge POCO to a View when you only need 3 fields from it; the ViewModel fixes this.
There are domain patterns like Domain Model and Active record. You do not have to have your domain objects be DDD. Active Record is the '1 record per object' mapped cleanly to the database. This occurs a ton in web forms applications.
There are data patterns like Direct Access, Web Form Controls (direct binding and access), Repository, and Unit of Work. While the Repository pattern is heavily debated, I really like it. As an architect it is such a small effort, for a clean and well working implementation. How could you ask for anything more? There was also some conversations on layering and when to do it vs. not do it. I wrote an entire post on this recently and feel that layers are fine: Layers Are Cheap, But Doing It Right Is Priceless This 1 paragraph is something I have professional passion about (see key note from yesterday about why I describe the type of passion) and could go on for hours discussing the pros/cons.
Adam began to show what happens when the Controllers begin to get 'fat'. If you are calling EF directly in the controller, you might want to refactor out this logic into another service layer. Also with the approach of fat controllers is that your unit tests against the controller will actually be integration testing since the code within will hit the actual database.
Dependency Injection was brought up and how it helps promte good testing techniques. A couple of quick comments on DI in web forms. Most of us are using MVC which has a dependency resolver built in, but web forms does not. Apparently AutoFac and Spring.NET have the ability to do both property and constructor injection. A method which I have used is combining a DI framework with using a Service Locator to Global.asax in the page's constructor. One feature of using a DI framework that even without true constructor injection that is useful is the management of mapping concrete types to their Interface counterpart in a single spot. My web form may not be easily testable, but all the methods and layers downstream that are dependent on the Interfaces being injected are tested more easily.
One last tidbit - EF6 allows mocking out an entity context.
Patterns and Tools for Parallel Programming
Marcel de Vries, Technology Manager and Microsoft MVP, InfoSupport
Parallel Programming = AWESOME.Simple principal: do more than 1 thing at a time simultaneously. In the world of multi-core machines, we need to leverage async when applicable.
Here is something interesting: Amdahals law - The maximum scale up that can be achieved is the lowest bit of sequential programming in your application. In a nutshell we are still slowed down by the lowest common denominator. However we can still speed up by a factor the overall programming execution time.
Marcel spoke to the difference between data parallelism and task parallelism. Data parallelism distributes the data across separate parallel computing nodes. In comparison, task parallelism distributes threads across separate parallel computing nodes.
A Task<T> is an asynchronous operation that can return a value of T. While a Task is lightweight we need to make sure we are saving 200-300 cycles of processing in order to make it asynchronous otherwise it is not worth it. Adding 2 integers is not efficient. You really want to offload a chunk of processing to surpass the instantiation of the Task object (which is small but still exists).
To avoid race conditions you need to add lock statements to your code. Hardware locking can be used for better performance via System.Threading.Interlockd.Increment/Decrement, etc.. The best method though is to write lock free code; meaning the code doesn't need to have locking to be accounted for in the 1st place. This can take some serious refactoring though for an existing application.
The Concurrency Visualizer was an awesome tool in VS.NET under the 'Analyzer' menu to show how the code is executing against the CPU available on the machine. This is a great way to analyze how the processing of your application is performing against the cores and how many it is using. In ordinary circumstances only a single core will be used. If you have intensive processing occurring this core can get pegged. If you add asynchronous programming to the process, you will see additional cores utilized and the amount of times to process (should) decrease.
Using Task.Factory.StartNew will issue a new process that TPL will load onto the different cores available. Also note that the order of the tasks being run is not in the order they are created; the order executed if all created at the same time is random. The TPL scheduler is optimized for tasks that run on average between 1 or 2 seconds. Marcel created an example that queued up 100 Tasks each taking a second or so to run. The problem is running that many tasks made the system add threads to the app pool which means down the line processing is not as efficient by over-committing the thread pool. A better approach is to seek out how many threads exist on the machine and then clean up each thread after it's complete.
The next example presented was showing the need to execute a series of unrelated but identical tasks and then create a summary of the data at the end. TPL makes solving this almost trivial using .ForEach(). (INSERT LINK HERE!!!!!!!!!!!!!!!!!)
PLINQ allows using LINQ with parallel task library underneath. It all runs on IEnumerable<T> and everything after the .AsParallel() call is executed in parallel on a Task.
Another informal poll:
How many are doing Win 8 app development: 2 hands
iOS development: 2 hands
Android apps: none
Web Apps: 95%
It appears ASP.NET is alive and well :D
The session was finished off with Async/Await. FINALLY, FINALLY, FINALLY, Marcel did an example that answered one of my questions on using async. Almost all of the examples I see await the Task on the same line of code. Isn't that then still synchronous? I believe yes. The idea and what I have done in practice is to call the Async method, do some independent work (in Marcel's example: DoIndependantWork()) and then await the task. This way we defer to a separate thread so we can do some other work.
However I did get the question in about all of the examples calling 'await' directly on the line calling the 'async' method. To me this was just a synchronous process. Marcel did confirm this to be true as it will block on that call and not proceed until it is done. But, there is still a benefit that I did not realize even with doing this method. Even though the async process is blocking, it is not blocking the UI thread. The result - while that potentially long running async method that is blocking is running, the UI is responsive. This actually is a huge benefit I did not realize. If the MSDN would just place that small tidbit that Marcel delivered it would have been understood much better on my end.
It is important though quantify your code/CPU/thread performance when doing any kind of parallelism. It appears 90-95% of the time when used correctly it will actually speed up execution. However there are some instances where doing TPL, PLINQ, etc. can actually hinder the performance so if there is any questions use metrics to quantify if the process is actually more efficient.
.NET Rocks! & Xamarin: Building Modern Apps Leveraging the Cloud
Andrew Brust, Richard Campbell, Andrew Connell, Carl Franklin, Don James, Rocky Lhotka, Matt Nunn, and Brian Randell
I'm new to 'The Tablet Show' or 'IT Rocks' podcasts but apparently this wrap up session for the mid-section of the conference will take on this format. They are actually about to release their 1000 podcast, so where have I been??
The show is actually really cool and has a nice format. Right now the discussion was surrounding Cordova (PhoneGap) and making Windows development easier across platforms. It wasn't interactive with the audience but rather a reading of some comments from their blog.
Moving on, there was in introduction of the panel on stage which included Rocky Lhotka, Billy Hollis, and Andrew Brust which were all speakers (in addition to the .NET Rocks guys) at the conference.
The discussion jumped right into something I discussed in my previous blog posts about 'What is a Hybrid App?' The explanation was actually long and in depth and not something that can be summarized in a few words. The problem with that type of answer is it does not necessarily clear up the understanding to the masses what a 'Modern App' actually is. However, Rocky came in and articulated well a bit better (or at lease better for my ears to understand) to clear up some of the understanding.
A lot of the conversation converged around how to manage a single platform vs. writing against several. A point was made this movie was seen before in the 90's even with having multiple front ends to a single back end in the likes of VB6 and PowerBuilder for example. The fragmentation that exists is not helping to make any of us in the industry understand understand exactly the clear future path. That might be an oxymoron anyway as knowing the future is not possible. That's why we have words like 'guess', 'crystal ball', 'speculate', and even 'crystal ball' :) The debate or better conversation was each panelist thoughts on what a 'Modern App' entails.
What was really cool, was Rocky mentioned at the beginning of the week getting in an argument with a gentleman about the end of Moore's law. Well it turned out to be one of the .NET Rocks guys on stage that was originally on the other side of that argument, who unknowingly explained in not so many words essentially the end of Moore's Law. Rocky brought up the previous argument and that he finally proved his point, "thank you for agreeing with me." Zing!!
The best conversation though surrounded where do we go in the enterprise in the future? Since we have all these different platforms with and Android, iOS, Windows, there are very few technologies that will work across all systems. Rocky believes that JavaScript and HTML will probably reign supreme. That's because these do run across all of the aforementioned platforms.
I'll step in and provide my own comments which are that I can believe how JS and HTML5 will reign supreme. According to the polls talken this week about 90%+ of the attendees are some type of web developer. Combine this with the fact that multiple platforms in the future will only continue to increase, we will be forced to figure out a way to develop efficiently and not have 6 different versions of the code base. Thus having our hand forced to develop using something that is cross platform and with the vast amount of web developers in the present day, we will naturally gravite (and possibly comfortably) to using JS and HTML5.
CRUD apps going away? All I have to say to this is, not in the busniess and corporate world.
Last question, "where will we be in 1 year?" My best guess is right here in Orlando still trying to figure out where we'll be the year after next. ;)
Wrap Up Day 4
Well the week is flying by and this wraps up the 75 minute session tracks portion of the conference. Being an ASP.NET dev in some fashion for a large slice of the pie, I decided to stick to mostly ASP.NET sessions. By the results of the informal polls and the attendance in these sessions, it appears technologies like ASP.NET, Entity Framework, and even native .NET Framework capabilities (i.e. Parallelism) are all alive and well and quite popular.
We need to be careful to not create panic and worry for the sake of panic and worry about the future. We have never been able to predict the future and many industries move at the speed of a turtle anyway so bleeding edge direction and decisions are not even on the radar for a significant portion of the development world. It's not to say we should be naive and ignore the future thus making poor decisions now (i.e. let's build our new major Enterprise app using Silverlight), but rather we may not need to do an about face just yet. Worst case scenario is we have to write and manage applications for 5 different platforms and the demand for software developers skyrockets. Hummm.... sounds like a good problem to have, and a little bit like natural job security. It's a better conversation to have then having to be concerned about an industry drying up or becoming non-existent.
Award for quote(s) of the day
"Do you think Windows will ever be free?" (.NET Rocks)
"What were they thinking serving baked beans at a developer conference????" (lunch line - anonymous)
No comments:
Post a Comment