LINQ All: it’s not all true

Pop quiz!

Will the program below throw an exception when executed?

	using System;
	using System.Collections.Generic;
	using System.Linq;
	class Review
	{
	public int Score { get; set; }
	}
	class Program
	{
	static void Main(string[] args)
	{
	var reviews = new List<Review>();
	if (reviews.All(r => r.Score < 0))
	throw new Exception("Alert manager");
	}
	}

view raw

linq-all-gotcha.cs

hosted with ❤ by GitHub

Now try running it to see the result, you might be surprised 🙂

Not intuitive, now is it.

 

Advertisement

Async / await best practices summary

Nice succinct summary of some async / await best practices:

https://channel9.msdn.com/Shows/On-NET/Brandon-Minnick-asyncawait-best-practices

It’s so easy to violate these, so be warned.

If you can’t be bothered to watch the short video, here’s the pay off:

 

 

SQL-92 ‘Til Infinity

Think you know SQL, then take this quick quiz at windowfunctions.com

It’s a lovely part quiz (10 questions), part tutorial experience, that will surely teach you a thing or two (or nine in my case, after the first question I was lost already)

If you’re anything like me, coming from a developer perspective, you can get your SQL-92 on, but anything a bit more smart or analytical gets complicated quickly.

You heard of  the OVER clause, but do your best to avoid needing it, right.
Or you think these SQL Server analytic functions and ranking functions have just been released. Well, this straightforward quiz made me finally “get” some of the basics and made the whole deal less intimidating, recommended.

Theme music for this blog post

Chamath Palihapitiya

Multi Model SQL Server

Graph database

SQL Server is introducing graph support. What I find great, is that you can mix it in your traditional relation database, so there’s no big to-SQL or NoSQL decision necessary.

This makes graphs a very feasible option in Microsoft (eco)systems, since you can start using this transparently to your IT infrastructure/department. Standard SQL Server operation and maintenance  procedures apply, no need to go through the pains of introducing an “exotic” to them database which noone has any experience running in production.

Document store

That’s in SQL Server 2017, what I totally missed in 2016 though, is the built-in JSON support. And I thought Marten was unique for .NET with its approach of exploiting the JSON support in Postgresql, to create a robust document store.

NoSQL – No SQL Server Marketing

I don’t have any experience with the graph or JSON support in SQL Server yet, so I might be missing something. And I’m sure a pure bred NoSQL product can go an extra mile or more. But I get the impression SQL Server responded to the NoSQL hype, and then didn’t really sell its new features to .NET developers.

Just last month at work, we were still discussing MongoDB to store documents and weighing whether taking on a new database technology in a Microsoft shop would be worth it, and we didn’t even consider SQL Server as a document option!

Obviously you can always build your own solution in SQL Server, but who has the time for that.

Now Cosmos DB markets itself as the all-in-one database for the cloud, but on-premise it looks like SQL Server will still get you from A to B.

Theme music for this blog post

 

Handling a user transaction that spans multiple distributed systems

Jimmy Bogard’s excellent series on building a resilient distributed process apparently also comes as a talk.

In an hour he basically communicates the gist of Enterprise Integration Patterns and spells out what to watch out for and how to approach, learning about how to approach a distributed transaction (where MSDTC or the likes isn’t an option) doesn’t get any simpler than this.

String.CopyToUpper

So I just finished Writing High-Performance .NET Code, which is dry at times, but contains nuggets of wisdom.

One of them was something I should’ve understood, but really only now dawned on me.

Strings are immutable.

But like, really immutable.

This means any operation on them like calling ToUpper, results in the creation of a new string.

This behavior makes sense ofcourse, since they are immutable. You’re even reminded in the docs:

This method does not modify the value of the current instance. Instead, it returns a new string in which all characters in the current instance are converted to uppercase.

– https://msdn.microsoft.com/en-us/library/ewdd6aed(v=vs.110).aspx

But intuitively while programming in your IDE, I will easily forget that I’m creating a new string. Unwittingly you could be increasing pressure on the garbage collector, deteriorating application performance, if you don’t pay attention in a hot application loop.

And I understand the string abstraction shouldn’t leak implementation details. But on the other hand, a name that is honest about what you are doing like .CopyToUpper, would save a lot of wasted CPU cycles in applications passed and to come 🙂

Theme music for this blog post

.NET HttpClient should be shared

While toying around with Azure Functions for some app idea, I came across some documentation on best practices for using it.

The article continues further into detail on Patterns and Practices HTTP Performance Optimizations where I discovered something about HttpClient I would have never guessed:

[HttpClient is] intended to be instantiated once and reused throughout the lifetime of an application. However, it’s a common misunderstanding that these classes should be acquired only as necessary and released quickly

new HttpClient object is created for each user request. Under heavy load, the web server may exhaust the number of available sockets, resulting in SocketException errors.

The HttpClient class is designed to be shared rather than pooled

Well whaddayaknow, until know I have always designed my applications to keep the HttpClient as short-lived as possible, always wrapping it in a using block to ensure proper disposal.

Turns out this is an anti-pattern, they actually advice you to create a static readonly HttpClient, which you reuse in your app.

Going to apply some improvements right now!

Theme music for this blog post

GraphQL as a silver bullet

I learned about GraphQL somewhere this year and thought it was genius.

Check out the official site to see what it is, but in short, you call an API and specify in your request the response contract you expect. This sounds lovely for supporting a wide range of use cases with a single API. No upfront rigid API contract, let the clients decide how they want the data.

So in my mind this sounded like the future for providing flexible API’s.

Thankfully the Internet provided some critical thinking, check out this presentation for a guide on when REST still trumps GraphQL:

https://www.infoq.com/presentations/api-rest-graphql

Highlights are your ability to rely on HTTP caching with REST and the self describing nature of HTTP verbs, things you lose with GraphQL.

And so the universally correct answer continues to be “its depends”.

Theme music for this blog post

Conversational website

I’ve been exploring the topic of chatbots with Designing Bots: Creating Conversational Experiences , Bot Business 101 and Chatbots for eCommerce: Learn how to build a virtual shopping assistant

While researching further online, I came across this developer’s personal website:

https://azumbrunnen.me/

The site is a chatbot that introduces him and allows you to learn more about him and get in touch. That’s a great way to present your work and what you can do, especially if your a bot developer!

Theme music for this blog post