Here’s a minor inconvenience that I’m going to put out there in the hope that one or two of the horrible people responsible for it may realize the errors of their ways and make the world a marginally better place.

So you like your titles to be all caps. Fine. I’m not sure why you insist on screaming like that, but that’s your choice, and it’s your web site/blog. If you are going to do this, however, please don’t do this:

@post.Title.ToUpper()

And not just because you neglected to specify a culture (you monster). No, this is wrong because next time the guy who builds the week in .NET wants to mention your site and copies the title over, he’s going to copy this:

HOW TO USE ENTITY FRAMEWORK TO KILL PUPPIES!!!

instead of this:

How to use Entity Framework to make a rainbow

He’s going to curse loudly, his kids may hear him, and they’ll grow up to become as obnoxious as he is, all because of you. Well done.

This is particularly infuriating because there is a perfectly good way to do this bad thing that you insist on doing. In your CSS, just do something like this:

h1 { text-transform: uppercase; }

There. Was that so hard?

Except that no. When you copy text that has been styled this way, you’ll still get the all caps text instead of the unstyled underlying text. F@$#!

OK.

Fine.

Just don’t .ToUpper your titles. Please. It looks like crap and it’s less readable. And you sound like a Facebook comment from that uncle who ruins Thanksgiving every year.

If you need to store your users' passwords, it's essential that you never store them plainly. Instead you must store a cryptographic hash of them, so that people who get access to your database don't get the passwords. Cade and Daniel explain how to do this properly: salting the hash to avoid lookup table attacks, and using an appropriate hashing algorithm to defend against well-equipped attackers.

more…

Introduction

These days our customers expect their applications to be up and running all the time and literally experience no down-time at all ever. At the same time we should be able to add new features to the existing application or fix existing defects. Is that even possible? Yes, it is, but it is not for free. We have to make a certain effort to achieve what is called zero-downtime deployments.

This post is part of my series about Implementing a CI/CD pipeline. Please refer to this post for an introduction and a full table of contents.

Zero down-time

If we need to achieve zero down-time then we can not use the more classical way of deploying new versions of our application. There we used to stop the current version of the application and put up the maintenance page for all our potential users that wanted to use the application while we were deploying. We would tell them something along the line

“Sorry, but our site is currently down for maintenance. We appologize for the inconvenience. Please come back later.”

But we cannot afford to do that anymore. Every minute of down-time signifies a lot of missed opportunities and with that potential revenue. So what we have to do is install the new version of the application while the current version is still up and running. For that we need to either have additional servers at hand to which we can install the new version or we need to find a way how we can have to versions of the same application running on the same servers. This is also called a non destructive deployment.

Since we leave the current version running while we deploy the new bits we (usually) have more time to execute the deployment. Once the new version is installed we can run some tests against it – also called smoke tests – to make sure the application is working as expected. We also use this opportunity to warm up the new application and potentially pre-fill the caches (if we use any) so that once it is hit by the public it is operating with maximal speed.

It is important to notice that during this time the new application is not visible to the public and we can only reach it internally to e.g. test it. Once we’re sure the new version is working as expected we reconfigure the routing from the current version to the new version. This reconfiguration happens (near to) instantaneous and all public traffic is now funneled through the new version. We can keep the previous version around for a while until we are sure that no unexpected fatal error was introduced with the new version of the application.

Rollback

Bad things happen, it’s just a sad truth. Sometimes we introduce a severe bug with a new release of our software. This can happen no matter how good we test. In this situation we need a way to rollback the application to the previous know good version. This rollback needs to be fool proof and quick.

When we are using zero-downtime or non-destructive deployment we gain this possiblity for free. Since the new version has been deployed without destroying or overwriting the previous version the latter is still around as long as we want after we have switched the public traffic over to the new version. We thus “only” need to redirect the traffic back to the old version if bad things happen. Again, re-routing traffic is a near instantaneous operation and can be fully automated so that a rollback is absolutely risk-free.

Compare this with a rollback in the case of a classically deployed application which used to be destructive. Once the new version was in place the old version was gone. One had to find the correct previous bits and re-install them… a nightmare! Most often the necessary steps to execute during a rollback were maybe documented but never exercised. A huge risk and nerve wrecking for everyone.

Schema Changes

The attentive reader may now say: “Wait a second, what about the case where a deployment encompasses breaking database schema changes?”

This is an interesting question and it needs some further discussion. I will go into full details in an upcoming post dedicated to this topic. Suffice to say at this point that there is a recommended best practice how to exercise breaking schema changes in situations like these. In a nutshell, we need to deploy schema changes separately from code changes and ALWAYS make the schema changes such as that they are backwards compatible. I promise, I’m going to describe the how and why in much more details in this upcoming post. Please stay tuned.

Blue-Green Deployment

Ok, now we have spoken about non destructive deployment and zero downtime deployment. There are various ways how this can be achieved. One is called Blue-Green Deployment. In this case we have a current version up and running in production. We can label this version as the blue version. Then we install a new version of our application in production. This time we label it with the color green. Once green is completely installed, smoke tested and ready to go we funnel all traffic through it. After waiting for some time until we are sure that no rollback is needed the blue version is now obsolete and can be decommissioned. The blue label is now free. When we deploy yet a newer version we will call it the blue version, and so on and so on. We are permanently switching from blue to green to blue to green.

Implementation Details

Let’s assume we are going to use blue-green deployment for a micro service called Foo. This service Foo is currently running in production and is at version v3. In a blue-green scenario each service has a color assigned. Let’s assume that we are currently blue. So far we talked about a logical service when we talked about Foo. But now let’s go to the physical components. Since our service needs to be highly available we run at least three instances of the service. We call them Foo-1-blue, Foo-2-blue and Foo-3-blue. These are now 3 physical instances of the logical blue service Foo. They run on different nodes (where node is either a VM or a physical server). We have a reverse proxy in front of the service which load-balances the traffic to the 3 instances using e.g. a round robin algorithm. We can use e.g. Nginx or HAProxy, etc. for this task.

If now another service say Bar needs to access Foo then it will make the request to a load balancer or reverse proxy which makes the color decision. Currently this one is configured to route the traffic to blue. For clarification please see the graphic below

Now it is time to deploy v4 of the service Foo. This new version gets the color green assigned. We once again for high availability reasons deploy 3 instances of the new version of the service. We call those 3 instances Foo-1-green, Foo-2-green and Foo-3-green. These 3 instances can be deployed to new nodes or if possible and requested coexist with the blue versions on the same nodes. Once we have smoke-tested and warmed up the new instances we can now reconfigure the router that controls the color. It will now funnel all public traffic through the green version as shown in the graphic below.

As you can see, the blue version of the service is still there and can be used in case we have to exercise a rollback.

Summary

In this post I have discussed in detail what zero-downtime deployments are and how this can be achieved by using the technique on non-destructive deployments. One variant of this latter technique is the so called blue-green deployment. These days this is a technique frequently used in fully automated CI/CD pipelines. This post is part of a series about Implementing a CI/CD pipeline.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In my last post, I talked about porting to .NET Core and requested feedback from our community on what their experience was and what we could improve.

This sparked many great conversations with our users.

Based on these conversations as well as our experience working with first- and third-party partners, we’ve decided to drastically simplify the porting effort by unifying the core APIs with other .NET platforms, specifically the .NET Framework and Mono/Xamarin.

In this blog post, I’ll talk about our plans, how and when this work will happen, and what this means for existing .NET Core customers.

Reflecting on .NET Core

The .NET Core platform evolved from a desire to create a modern, modular, app-local, and cross-platform .NET stack. The business goals that drove its creation were focused on providing a stack for brand new application types (such as touch-based UWP apps) or modern cross-platform applications (such as ASP.NET Core web sites and services).

We are about to ship .NET Core 1.0 and we have succeeded in creating a powerful and cross platform development stack. .NET Core 1.0 is the beginning of a journey to get .NET everywhere.

While .NET Core works well for the scenarios that we set out to address, it provides access to fewer technologies than other .NET platforms, especially the .NET Framework. Partly because not everything has been made cross platform, and partly because we aggressively trimmed some features out of it.

It became clear that adopting .NET Core would require existing .NET developers to spend a considerable amount of time to port to it.

While there is certainly some value in presenting new customers with a cleaner API, it disproportionately penalized our existing loyal customers who have invested over many years in using the APIs and technologies we advertised to them. We want to extend the reach of the .NET platform and gain new customers, but we can’t do so at the expense of existing users.

Xamarin is a great role model in this regard. They allow .NET developers to build mobile applications for the iOS and Android platforms with minimal effort. Consider iOS. It shares many of the characteristics of the UWP platform, such as the high focus on end-user experience and the requirement of static compilation. However, in contrast to .NET Core, Xamarin did not start with reimagining the .NET stack. They took Mono as-is, removed the application model components (Windows.Forms, ASP.NET), added a new one for iOS, and made minimal changes to make it suitable for embedded use. Since Mono is virtually identical to the .NET Framework, the resulting API set is fairly comprehensive and makes porting existing code to Xamarin substantially easier.

Since its inception the key promise of .NET has been to make developers more productive and help them write robust code. It was designed from the start to support developers on a wide range of areas and scenario, starting with desktop and web applications to microservices, mobile applications and gaming.

For us to deliver on our promise, it is critical that we provide a unified core API that is available everywhere. A unified core API allows developers to easily share code across these workloads and allows them to focus their skills where it matters the most – creating great services and user experiences.

.NET Core moving forward

At Build 2016, Scott Hunter presented the following slide:

Here is the promise we want to make to you:

Whether you need to build a desktop application, a mobile app, a web site, or a micro service: you can rely on .NET to get you there. Code sharing is as easy as possible because we provide a unified BCL. As a developer, you can focus on the features and technologies that are specific to the user experiences and platforms you’re targeting.

This is how we want to realize this promise: we will provide source and binary compatibility for applications that target the core Base Class Libraries (BCL) across all platforms with the same behavior across platforms. The Base Class Libraries are those that existed in mscorlib, System, System.Core, System.Data, and System.Xml and that are not tied to a particular application model and are not tied to a particular operating system implementation.

Whether you target the .NET Core 1.0 surface (System.Runtime-based surface), or the upcoming version of .NET Core with the expanded API (mscorlib-based surface), your existing code will continue to work.

The promise of making it easier to bring existing code extends to libraries and NuGet packages. Obviously this includes portable class libraries, regardless of whether they used mscorlib or System.Runtime.

Here are a few examples of the additions that will make your life easier when targeting to .NET Core:

• Reflection will become the same as the .NET Framework, no need for GetTypeInfo(), good old .GetType() is back.
• Types will no longer miss members we’ve removed for clean up reasons (Clone(), Close() vs Dispose(), old APM APIs)
• Binary serialization (BinaryFormatter) will be available again

A full list of the planned additions will be made available in our corefx GitHub repo.

What does this mean for .NET Core?

From talking to our community on social media it seems there is a concern that these API additions degrade the .NET Core experience. Nothing could be further from the truth. The vast majority of investments we made for .NET Core, be it that it can be deployed in an app-local fashion, XCOPY deployment, that we have an ahead-of-time (AOT) compiler tool chain, that it’s open source and cross- platform remain unchanged. The same is true for all the additional features and performance improvements we made, such as the new networking component called Kestrel.

Originally, when we designed .NET Core we’ve talked heavily about modularization and pay for play, meaning you only have to consume the disk space for the features that you end up using. We believe we can still realize these goals without compromising so heavily on compatibility.

Initially, our plan to achieve minimum disk space usage relied on a manual process of splitting the functionality in tiny libraries and we know that our users liked this. We will now provide a linking tool that will be more precise and provide better savings than any manual process could have provided. This is similar to what Xamarin developers get today.

Timelines and process

The process to extend the API surface of .NET Core will come after we ship .NET Core 1.0 RTM. This way, those of you that have been following along .NET Core will be able to deploy to production.

You can expect to see more details and plans over the next couple of weeks published in our corefx GitHub repository. One of the first things we will do is to publish a set of API references that list which APIs we’re planning to bring. So when porting code you will be able to tell whether you want to jump to .NET Core 1.0 or wait for the new APIs to come. We’ll also call out which APIs we don’t plan on bringing. Our desire is to provide a dashboard for our users to check on the project status and goals.

This will be an improvement over the process that we followed in the lead up to .NET Core 1.0, as we did not share enough of our internal processes with the world.

Lastly, we’re planning on releasing incremental updates to .NET Core on NuGet that extends the set of available APIs. This way, you will not have to wait until all the API additions are done in order to take advantage of them. This also allows us to incorporate your feedback on behavioral compatibility.

Over the next weeks we will publish more details in the corefx repo. You can expect this blog to communicate the status and all major decisions.

Stay tuned for more details!

Un réseau social d’entreprise ?

Disponible en location ou dans le cadre d’évènements pour le grand-public, la Foosball Society a pour vocation de changer en profondeur les relations entre les joueurs, les entreprises et les marques.

La start-up dévoilera son système à l’occasion du festival Futur-en-Seine.

Locks are tricky; I thought today I’d talk a bit about some of the pitfalls of locking that you might not have seen before.

As you probably know, the lock statement in C# is a syntactic sugar for the use of a monitor, so I’ll use the terms “lock” and “monitor” somewhat interchangeably. A monitor is an oddly-named data structure that gives you two basic operations: “enter” the monitor and “exit” the monitor. The fabulous thing about a monitor is that only one thread can enter a given monitor at a time; if threads alpha and beta both attempt to enter a monitor then only one wins the race; the other blocks at least until the winner exits. After the winner exits the monitor, the loser gets another chance to attempt to acquire the monitor; of course, there might be another race.

I give an example of a very very simple implementation of a monitor here, though of course you would never do this yourself; you’d just use the built-in support in the framework and the C# language.

The lock(x) { body } statement in C# is a syntactic sugar for

bool lockWasTaken = false;
var temp = x;
try 
{ 
  Monitor.Enter(temp, ref lockWasTaken); 
  { 
      body 
  }
}
finally 
{ 
  if (lockWasTaken) 
    Monitor.Exit(temp); 
}

The details of how the operating system implements (or fails to implement!) a system whereby every thread gets access eventually in some sort of fair manner is beyond the scope of what I want to talk about today. Rather, I want to talk about an advanced use of monitors. In addition to the straightforward “enter, do some work, exit” mechanism, monitors also provide a mechanism for temporarily exiting a monitor in the middle of a lock! That is, for the workflow:

• block until I enter the monitor
• do some work
• temporarily exit the monitor until something happens on another thread that I care about
• when the thing I care about happens, block until the monitor can be entered again
• do some work
• exit the monitor

Under what circumstances would we want to do this? The classic example is that we have a not-threadsafe finite-size queue of jobs to perform, and two threads called the producer and the consumer. The consumer thread sits there in a loop attempting to remove items from the queue so that the job can be performed. The producer thread runs around looking for work to do and puts it on the queue. Our code must have the following characteristics:

• if the consumer is attempting to modify the queue then an attempt by the producer to modify the queue must block
• and similarly vice versa
• if the producer is attempting to put work onto a full queue, it must block and allow the consumer to clear out space
• if the consumer is attempting to take work off of an empty queue, it must block and allow the producer to find more work

To achieve these goals, a monitor provides three operations in addition to enter and exit:

• “wait” causes the monitor to exit and puts the current thread to sleep. More specifically, it causes a thread to enter the “wait state”.
• “notify” — which, oddly enough is called Pulse in .NET — allows the thread which is currently in the monitor to place a single waiting thread (of the runtime’s choice) in the “ready” state. A ready thread is still blocked, but it is marked as ready to enter the monitor when the monitor becomes available. (There is no guarantee that it will do so; again, it might be racing against other threads.)
• “notify all” pulses every thread in the wait state that is waiting for a particular monitor.

Of course there are many other uses for these operations than producer-consumer queues, but as a canonical example we’ll stick with that for the purposes of this series.

What does the code typically look like? On the producer we’d have something like:

while(true)
{
  var someWork = FindSomeWork();
  lock(myLock)
  {
    while (myQueue.IsFull)
    { 
      Monitor.Wait(myLock); 
      // We cannot do any work while the queue is full. 
      // Put the producer thread into the wait state.
      // When someone pulses us, try to acquire the lock again,
      // and then check again to see if the queue is full.
    }
    // If we got here then we have acquired the lock,
    // and the queue has room.
    myQueue.Enqueue(someWork);
    // The queue might have been empty, and the consumer might be
    // waiting. If so, put the consumer thread in the ready state.
    Monitor.Pulse(myLock); 
    // The consumer thread, if it was asleep, is now ready, but we
    // still own the lock. Let's leave the lock and give it a chance
    // to run. It might lose the race of course.
  }
}

And on the consumer side we’d see something unsurprisingly similar. I won’t labour the point with excessive comments here.

while(true) 
{
  Work someWork = null;
  lock(myLock)
  {
    while (myQueue.IsEmpty)
      Monitor.Wait(myLock);
    someWork = myQueue.Dequeue();
    Monitor.Pulse(myLock);
  }
  DoWork(someWork);
}

OK, I hope that is all very clear. This was a long introduction to what is a surprisingly not-straightforward question: why did I write a loop around each wait? Wouldn’t the code be just as correct if written

  lock(myLock)
  {
    if (myQueue.IsEmpty) // no loop!
      Monitor.Wait(myLock);
    ...

Next time on FAIC: Yeah, what’s up with that?

La fonction d'économie de batterie de l'application mobile Uber sait détecter l'autonomie restante du téléphone. Selon les constatations de ce service de véhicule de transport avec chauffeur, les clients dont le smartphone est sur le point de s'éteindre seraient susceptibles d'accepter des...

I've been happy with my 2016 HTPC, but the situation has changed, largely because of something I mentioned in passing back in November:

The Xbox One and PS4 are effectively plain old PCs, built on:

• Intel Atom class (aka slow) AMD 8-core x86 CPU
• 8 GB RAM
• AMD Radeon 77xx / 78xx GPUs
• cheap commodity 512GB or 1TB hard drives (not SSDs)

The golden age of x86 gaming is well upon us. That's why the future of PC gaming is looking brighter every day. We can see it coming true in the solid GPU and idle power improvements in Skylake, riding the inevitable wave of x86 becoming the dominant kind of (non mobile, anyway) gaming for the forseeable future.

And then, the bombshell. It is all but announced that Sony will be upgrading the PS4 this year, no more than three years after it was first introduced … just like you would upgrade a PC.

Sony may be tight-lipped for now, but it's looking increasingly likely that the company will release an updated version of the PlayStation 4 later this year. So far, the rumoured console has gone under the moniker PS4K or PS4.5, but a new report from gaming site GiantBomb suggests that the codename for the console is "NEO," and it even provides hardware specs for the PlayStation 4's improved CPU, GPU, and higher bandwidth memory.

• CPU: 1.6 → 2.1 Ghz CPU
• GPU: 18 CUs @ 800Mhz → 36 CUs @ 911Mhz
• RAM: 8GB DDR5 176 GB/s → 218 GB/s

In PC enthusiast parlance, you might say Sony just slotted in a new video card, a faster CPU, and slightly higher speed RAM.

This is old hat for PCs, but to release a new, faster model that is perfectly backwards compatible is almost unprecedented in the console world. I have to wonder if this is partially due to the intense performance pressure of VR, but whatever the reason, I applaud Sony for taking this step. It's a giant leap towards consoles being more like PCs, and another sign that the golden age of x86 is really and truly here.

I hate to break this to PS4 enthusiasts, but as big of an upgrade as that is – and it really is – it's still nowhere near enough power to drive modern games at 4k. Nvidia's latest and greatest 1080 GTX can only sometimes manage 30fps at 4k. The increase in required GPU power when going from 1080p to 4k is so vast that even the PC "cost is no object" folks who will happily pay $600 for a video card and $1000 for the rest of their box have some difficulty getting there today. Stuffing all that into a $299 box for the masses is going to take quite a few more years.

Still, I like the idea of the PS4 Neo so much that I'm considering buying it myself. I strongly support this sea change in console upgradeability, even though I swore I'd stick with the Xbox One this generation. To be honest, my Xbox One has been a disappointment to me. I bought the "Elite" edition because it had a hybrid 1TB drive, and then added a 512GB USB 3.0 SSD to the thing and painstakingly moved all my games over to that, and it is still appallingly slow to boot, to log in, to page through the UI, to load games. It's also noisy under load and sounds like a broken down air conditioner even when in low power, background mode. The Xbox One experience is way too often drudgery and random errors instead of the gaming fun it's supposed to be. Although I do unabashedly love the new controller, I feel like the Xbox One is, overall, a worse gaming experience than the Xbox 360 was. And that's sad.

Or maybe I'm just spoiled by PC performance, and the relatively crippled flavor of PC you get in these $399 console boxes. If all evidence points to the golden age of x86 being upon us, why not double down on x86 in the living room? Heck, while I'm at it … why not triple down?

This, my friends, is what tripling down on x86 in the living room looks like.

It's Intel's latest Skull Canyon NUC. What does that acronym stand for? Too embarrassing to explain. Let's just pretend it means "tiny awesome x86 PC". What's significant about this box is it contains the first on-die GPU Intel has ever shipped that can legitimately be considered console class.

It's not cheap at $579, but this tiny box bristles with cutting edge x86 tech:

• Quad-core i7-6770HQ CPU (2.6 Ghz / 3.5 Ghz)
• Iris Pro Graphics 580 GPU with 128MB eDRAM
• Up to 32GB DDR4-2666 RAM
• Dual M.2 PCI x4 SSD slots
• 802.11ac WiFi / Bluetooth / Gigabit Ethernet
• Thunderbolt 3 / USB 3.1 gen 2 Type-C port
• Four USB 3.0 ports
• HDMI 2.0, mini-DP 1.2 video out
• SDXC (UHS-I) card reader
• Infrared sensor
• 3.5mm combo digital / optical out port
• 3.5mm headphone jack

All impressive, but the most remarkable items are the GPU and the Thunderbolt 3 port. Putting together a HTPC that can kick an Xbox One's butt as a gaming box is now as simple as adding these three items together:

1. Intel NUC kit NUC6i7KYK $579
2. 16GB DDR4-2400 $75
3. Samsung 950 Pro NVMe M.2 (512GB) $317

Ok, fine, it's a cool $970 plus tax compared to $399 for one of those console x86 boxes. But did I mention it has skulls on it? Skulls!

The CPU and disk performance on offer here are hilariously far beyond what's available on current consoles:

• Disk performance of the two internal PCIe 3.0 4x M.2 slots, assuming you choose a proper NVMe drive as you should, is measured in not megabytes per second but gigabytes per second. Meanwhile consoles lumber on with, at best, hybrid drives.

• The Jaguar class AMD x86 cores in the Xbox One and PS4 are about the same as the AMD A4-5000 reviewed here; those benchmarks indicate a modern Core i7 will be about four times faster.

But most importantly, its GPU performance is on par with current consoles. NUC blog measured 41fps average in Battlefield 4 at 1080p and medium settings. Digging through old benchmarks I find plenty of pages where a Radeon 78xx or 77xx series video card, the closest analog to what's in the XBox One and PS4, achieves a similar result in Battlefield 4:

I personally benchmarked GRID 2 at 720p (high detail) on all three of the last HTPC models I owned:

	Max	Min	Avg
i3-4130T, HD 4400	32	21	27
i3-6100T, HD 530	50	32	39
i7-6770HQ, Iris Pro 580	96	59	78

When I up the resolution to 1080p, I get 59fps average, 38 min, 71 max. Checking with Notebookcheck's exhaustive benchmark database, that is closest to the AMD R7 250, a rebranded Radeon 7770.

What we have here is legitimately the first on-die GPU that can compete with a low-end discrete video card from AMD or Nvidia. Granted, an older one, one you could buy for about $80 today, but one that is certainly equivalent to what's in the Xbox One and PS4 right now. This is a real first for Intel, and it probably won't be the last time, considering that on-die GPU performance increases have massively outpaced CPU performance increases for the last 5 years.

As for power usage, I was pleasantly surprised to measure that this box idles at 15w at the Windows Desktop doing nothing, and drops to 13w when the display sleeps. Considering the best idle numbers I've measured are from the Scooter Computer at 7w and my previous HTPC build at 10w, that's not bad at all! Under full game load, it's more like 70 to 80 watts, and in typical light use, 20 to 30 watts. It's the idle number that matters the most, as that represents the typical state of the box. And compared to the 75 watts a console uses even when idling at the dashboard, it's no contest.

Of course, 4k video playback is no problem, though 10-bit 4K video may be a stretch. If that's not enough — if you dream bigger than medium detail 1080p gameplay — the presence of a Thunderbolt 3 port on this little box means you can, at considerable expense, use any external GPU of your choice.

That's the Razer Core external graphics dock, and it's $499 all by itself, but it opens up an entire world of upgrading your GPU to whatever the heck you want, as long as your x86 computer has a Thunderbolt 3 port. And it really works! In fact, here's a video of it working live with this exact configuration:

Zero games are meaningfully CPU limited today; the disk and CPU performance of this Skull Canyon NUC is already so vastly far ahead of current x86 consoles, even the PS4 Neo that's about to be introduced. So being able to replace the one piece that needs to be the most replaceable is huge. Down the road you can add the latest, greatest GPU model whenever you want, just by plugging it in!

The only downside of using such a small box as my HTPC is that my two 2.5" 2TB media drives become external USB 3.0 enclosures, and I am limited by the 4 USB ports. So it's a little … cable-y in there. But I've come to terms with that, and its tiny size is an acceptable tradeoff for all the cable and dongle overhead.

I still remember how shocked I was when Apple switched to x86 back in 2005. I was also surprised to discover just how thoroughly both the PS4 and Xbox One embraced x86 in 2013. Add in the current furor over VR, plus the PS4 Neo opening new console upgrade paths, and the future of x86 as a gaming platform is rapidly approaching supernova.

If you want to experience what console gaming will be like in 10 years, invest in a Skull Canyon NUC and an external Thunderbolt 3 graphics dock today. If we are in a golden age of x86 gaming, this configuration is its logical endpoint.

[advertisement] Find a better job the Stack Overflow way - what you need when you need it, no spam, and no scams.

Big Blue a créé une mémoire à changement de phase (ou PCM pour phase change memory) combinant la vitesse et l’endurance de la DRam avec le faible coût de production de la mémoire flash. Ce compromis est un pas important vers la création d’une mémoire universelle qui doperait les...

Leader mondial des objets connectés de sport, Fitbit annonce le rachat de la startup Coin, qui développait un outil de paiement permettant d’émuler plusieurs cartes de crédit dans le cadre de paiements magnétiques et sans-contact.

Fitbit vient d’annoncer l’acquisition de la start-up américaine Coin, à l’origine d’une technologie de gestion du paiement mobile dédiée aux wearables, comme nous vous en parlions en 2013.

Comme son concurrent historique Jawbone –qui a parié très tôt sur les fonctions de paiement pour wearables en s’associant avec American Express– Fitbit mise sur la possibilité de payer ses achats à l’aide de ses objets connectés de tous les jours.

Fitbit rachète Coin

Fitbit fait ce pari en s’offrant l’essentiel des technologies développés par Coin, basée à San Francisco, et qui s’est faite connaître grâce à son système permettant de réunir plusieurs cartes de paiement (crédit, débit, fidélité…) sur un même objet connecté versatile.

Dans la pratique, l’utilisateur est invité à scanner ses différentes cartes bancaires à l’aide d’un lecteur relié à son smartphone et dont les informations sont transmises via Bluetooth à la carte Coin, grâce à une application dédiée pour iOS et Android.

Fonctionnement de Coin

La carte bancaire connectée de Coin, dotée d’un affichage et d’un bouton permettant de changer de cartes à volonté. Si la nouvelle version (2.0 de ce produit est arrivée il y a quelques mois déjà, ajoutant au passage la compatibilité avec les cartes à puce à la norme EMV, Coin avait échoué à convaincre les organismes bancaires de jouer le jeu… condamnant automatiquement le système au passage, comme précise Engadget dans son test du produit.

La commercialisation du produit devrait s’interrompre rapidement et le programme destiné aux développeurs va être suspendu.

Quel avenir pour Coin ?

En plus de ces incompatibilités, il fallait rajouter quelques difficultés supplémentaires avec les terminaux de paiement les plus anciens ou certains distributeurs de billets récalcitrants. Dans le cadre du rachat par Fitbit, les technologies associées à ce produit ont été évitées.

Le fabricant américain d’objets connectés de quantified self est leader mondial sur le marché des « wearables selon IDC et s’intéresse davantage à la plateforme de paiement développée par Coin, qui fait l’objet d’une alliance avec d’autres fabricants tels que Moov, Omate ou encore Atlas Wearables.

Fitbit attendra sans aucun doute plusieurs mois avant d’intégrer la technologie de Coin dans ses services maison, mais la nouvelle est intéressante car elle préfigure une sérieuse bataille entre les géants du secteurs, Swatch (avec sa montre Bellamy) et quelques autres en tête.

Via

Read 32 remaining paragraphs | Comments

Read 4 remaining paragraphs | Comments

La SNCF aurait investi environ 70 millions d’euros (selon BFM TV) dans le train supersonique Hyperloop, un projet initié par Elon Musk il y a quelques années. La compagnie ferroviaire n’a pas souhaité confirmer l’information.

Hyperloop pourrait bien être le TGV du futur tant il est rapide et innovant.

La SNCF a semble-t-il décidé de miser sur l’Hyperloop. Le projet, imaginé par l’entrepreneur star Elon Musk (SpaceX, Paypal, Tesla), vient de boucler sa deuxième levée de fonds pour continuer à affiner le fonctionnement de son mode de transport innovant.

Cette augmentation de capital, d’un montant total de 80 millions de dollars, aurait également été souscrite par les fonds GE Ventures et 137 Ventures.

Rappelons que la SNCF est le premier client d’Alstom –fabricant des TGV– et un allié important lorsqu’il s’agit de les commercialiser à l’international.

Les deux entreprises collaborent d’ailleurs à la mise au point de la prochaine génération du TGV, prévue à l’horizon 2020.

Mais la compagnie ferroviaire publique aurait décidé de ne pas mettre tous ses oeufs dans le même panier en misant également sur Hyperloop :

« Hyperloop est un projet à la fois allumé et visionnaire. Nous le suivons de près » – Guillaume Pepy à l’Obs, Sept. 2015

Deux mois après cette déclaration élogieuse, le patron partageait la scène avec Brogan Banbrogan, le cofondateur d’Hyperloop Technologies et avait réitéré son appel du pied : « Nous sommes intéressés par une coopération avec Hyperloop, car c’est une technologie de rupture (…) et nous avons besoin d’appréhender ce qui peut émerger d’ici 10 à 15 ans. »

Les contacts viennent manifestement de se concrétiser par un joli chèque pour la SNCF.

Fonctionnement d’Hyperloop

Déjà en test dans le désert du Nevada, le système de transport Hyperloop ne devrait pas arriver en Europe avant 2025 mais les premiers essais semblent concluants. Le fonctionnement de ce train supersonique est simple : des capsules sont déplacées à haute vitesse dans un ‘tube’ d’environ 2,5 mètres de diamètre.

Ces tronçons seront hermétiquement scellés les uns aux autres pour pouvoir maintenir une dépression à l’intérieur du conduit et de limiter les frottements lors du déplacement des véhicules.

En pratique, les passagers s’installeront au sein de petites navettes posées sur des coussins d’air. Celles-ci voyageront à plusieurs milliers de kilomètres par heure au sein de tubes à basse pressurisation…

A titre d’exemple, avec Hyperloop on pourra parcourir 4.500 km en 45 minutes… soit de New York à Los Angeles !

Le design de l’expérience utilisateur (UX design) impacte l’appropriation des objets connectés et influence les mécanismes de conception dans l’internet des objets. Cette variable est prise en compte dans le modèle développé au sein de la Chaire RSOC.

Dans le cadre de leur partenariat, Aruco publie régulièrement les travaux de la Chaire Réseaux Sociaux et Objets Connectés de l’école Télécom EM et de l’Institut Mines-Télécom.

Cet article est une introduction à l’univers complexe de l’User Experience Design adapté aux objets connectés ; la Chaire RSOC lancera prochainement une étude approfondie sur le sujet.

Design et objets connectés

Une expérience utilisateur réussie est l’une des clés de l’appropriation de ces nouveaux objets et services dans notre vie quotidienne.

Cet axe est d’autant plus important à approfondir lorsque l’on constate que plus d’un tiers des objets connectés sont abandonnés de manière définitive par leur utilisateur avant 6 mois d’utilisation seulement (étude GfK, 2014).

Cependant, le design de l’expérience utilisateur dans le cadre de l’Internet des Objets se révèle plus complexe que le design restreint à un simple service web.

La partie hardware ajoute des contraintes supplémentaires difficilement modifiables post-production, contrairement au logiciel qui pourra toujours être modifié à posteriori via une mise-à-jour.

Il est donc essentiel de penser et designer l’ensemble d’un objet connecté en amont.

Pourquoi l’UX design pour l’IoT est-il différent ?

Comme l’explique Claire Rowland (auteur du livre Designing Connected Products, 2015), spécialiste en UX design pour l’Internet of Things, designer un objet connecté nécessite une approche holistique.

Se concentrer sur les parties tangibles, comme le design industriel de l’objet ou bien le design d’Interfaces Utilisateur (ou UIs pour User Interfaces), n’est pas suffisant.

Ces deux derniers éléments ont un impact indéniable, et même majeur, sur l’expérience utilisateur finale. Cependant, de nombreux autres aspects dans la conception d’un objet connecté doivent être pris en compte.

IoT : un écosystème complexe

Comme l’illustre la cartographie « I MAKE THINGS » d’Alexandra Deschamps-Sonsino (designswarm), spécialiste en stratégie et IoT Design, les industries créatives ne cessent de se chevaucher.

L’Internet des Objets fait intervenir une multitude d’acteurs aux visions variées. Dans cet environnement, où monde physique et virtuel se rencontrent, software, hardware et éventuels services associés à l’objet connecté doivent être complémentaires.

Designers, Ingénieurs et Business ont ainsi besoin d’avoir une compréhension commune des objectifs afin de livrer un ensemble cohérent pour l’utilisateur final.

Les caractéristiques singulières d’un objet connecté

Un concepteur d’objets connectés doit garder en tête trois caractéristiques qui rendent ces objets si particuliers :

1. Leur capacité à faire le lien entre le monde physique et digital
2. Le fait que la plupart des objets connectés fassent partie d’un système multi-appareils
3. Les contraintes et opportunités que leur mise en réseau implique

L’interusabilité : kezako ?

Comme il vient de l’être mentionné, la majorité des objets connectés font souvent partie de systèmes multi-appareils. Les fonctionnalités peuvent être distribuées au travers de plusieurs appareils aux capacités différentes. L’un des rôles du designer est d’examiner la meilleure façon de distribuer ces fonctionnalités.

Ainsi, il devra designer l’UIs et les interactions à travers l’ensemble du système. Il ne faut pas oublier que le traitement des données collectées via ce système aboutit souvent à la création d’un service en ligne. Ce dernier élément devra également être pensé, designé et intégré à l’ensemble du système.

L’expérience globale du système est toute aussi importante que celle de l’appareil seul.

Concevoir l’expérience utilisateur dans son ensemble

Et ce n’est pas tout, si nous reprenons le modèle de Claire Rowland après l’Interusabilité se trouvent encore :

• Le Modèle Conceptuel : quelles sont les attentes de l’utilisateur vis-à-vis du système ? quelle est sa perception globale du système ?
• La Plateforme : élément essentiel pour gérer la complexité de ces systèmes multi-appareils.
• Le Service : un objet connecté est rarement synonyme d’une “vente one-shot”. Il est certainement accompagné d’un service impliquant une relation continue avec le concepteur.
• La Productization : le fait de transformer un concept ou bien une technologie en un produit commercialisable. En d’autres termes, réussir à créer une proposition de valeur évidente pour le public ciblé.

Avec toutes ces facettes, on comprend mieux pourquoi il est si tentant “d’oublier” certaines étapes dans la conception d’un objet connecté.

Comme le dit si bien Alexandra Deschamps-Sonsino :

“[…] that’s the trouble of the internet of things, there are too many touch points that need designing so we start with the easiest: the screen.”

Il faut ainsi veiller à ne pas se contenter de designer les parties tangibles d’un objet connecté, comme l’écran, et le penser dans son ensemble.

As an open source maintainer, it’s important to recognize and show appreciation for contributions, especially external contributions.

We’ve known for a while that after a person’s basic needs are met, money is a poor motivator and does not lead to better work. This seems especially true for open source projects. Often, people are motivated by other intrinsic factors such as the recognition and admiration of their peers, the satisfaction of building something that lasts, or because they need the feature. In the workplace, good managers understand that acknowledging good work is as important if not more so than providing monetary rewards.

This is why it’s so important to thank contributors for their contributions to your projects, big and small.

Seems obvious, but I was reminded of this when I read this blog post by Hugh Bellamy about his experiences contributing to the .NET CoreFX repository. In the post, he describes both his positive and negative experiences. Here’s one of his negative experiences.

In the hustle and bustle of working at Microsoft, many of my PRs (of all sizes) are merged with only a “LGTM” once the CI passes. This can lead to a feeling of lack of recognition of the work you spent time on.

Immo Landwerth, a program manager on the .NET team, gracefully responds on Twitter in a series of Tweets…

.@bellamy_hugh Thanks for the valid criticism and the points raised. We’ve started to work so closely with many contributors that team…

@bellamy_hugh …members treat virtually all PRs as if coming from Microsofties. This results reduction to essence, LGTM, and micro speak.

.@bellamy_hugh Quite fair to say that we should improve in this regard!

What I found interesting though was the part where they treat PRs if it came from fellow employees. That’s very admirable! But it did make me wonder, “WHA?! You don’t thank each other!” ;)

To be clear, I have a lot of admiration for Immo and the CoreFX team. They’ve been responsive to my own issues in the past and I think overall they’re doing a great job of managing open source on GitHub. In fact, a tremendous job! (Side note, Hey Immo! Would love to see a new Open Source Update)

This is one of those easy things to forget. In fact, I forgot to call it out in my own blog post about conducting effective code reviews. Recognition makes contributors feel appreciated. And often, all it takes is something small. It doesn’t require a ceremony.

GitHub Selfie to the rescue

However, if you want to add a little bit of ceremony, I recommend the third party GitHub Selfie Extension which is available in the Chrome Web Store as well as for Firefox.

One important thing to note is that this extension does a bit of HTML screen scraping to inject itself into the web page, so when GitHub.com changes its layout, it can sometimes be broken until the author updates it. The extension is not officially associated with GitHub.

I’ve tweeted about it before, but realized I never blogged about it. The extension adds a selfie button for Pull Requests that let you take a static selfie or an animated Gif. My general rule of thumb is to try and post an animated selfie for first time contributions and major contributions. In other cases, such as when I’m reviewing code on my phone, I’ll just post an emoji or animated gif along with a simple thank you.

Here’s an example from the haacked/scientist.net repository.

My co-worker improved on it.

Here’s an example where I post a regular animated gif because the contributor is a regular contributor.

However, there’s a dark side to GitHub Selfie I must warn you about. You can start to spend too much time filming selfies when you should be reviewing more code. Mine started to get a bit elaborate and I nearly hurt myself in one.

These became such a thing a co-worker created a new Hubot command at work .haack me that brings up a random one of these gifs in Slack.

Anyways, I’m losing the point here. GitHub Selfie is just one approach, albeit a fun one that adds a nice personal touch to Pull Request reviews and managing an OSS project. There are many other ways. The common theme though, is that a small word of appreciation goes a long way!

Read 1 remaining paragraphs | Comments

Read 51 remaining paragraphs | Comments

You know what's universally regarded as un-fun by most programmers? Writing assembly language code.

As Steve McConnell said back in 1994:

Programmers working with high-level languages achieve better productivity and quality than those working with lower-level languages. Languages such as C++, Java, Smalltalk, and Visual Basic have been credited with improving productivity, reliability, simplicity, and comprehensibility by factors of 5 to 15 over low-level languages such as assembly and C. You save time when you don't need to have an awards ceremony every time a C statement does what it's supposed to.

Assembly is a language where, for performance reasons, every individual command is communicated in excruciating low level detail directly to the CPU. As we've gone from fast CPUs, to faster CPUs, to multiple absurdly fast CPU cores on the same die, to "gee, we kinda stopped caring about CPU performance altogether five years ago", there hasn't been much need for the kind of hand-tuned performance you get from assembly. Sure, there are the occasional heroics, and they are amazing, but in terms of Getting Stuff Done, assembly has been well off the radar of mainstream programming for probably twenty years now, and for good reason.

So who in their right mind would take up tedious assembly programming today? Yeah, nobody. But wait! What if I told you your Uncle Randy had just died and left behind this mysterious old computer, the TIS-100?

And what if I also told you the only way to figure out what that TIS-100 computer was used for – and what good old Uncle Randy was up to – was to read a (blessedly short 14 page) photocopied reference manual and fix its corrupted boot sequence … using assembly language?

Well now, by God, it's time to learn us some assembly and get to the bottom of this mystery, isn't it? As its creator notes, this is the assembly language programming game you never asked for!

I was surprised to discover my co-founder Robin Ward liked TIS-100 so much that he not only played the game (presumably to completion) but wrote a TIS-100 emulator in C. This is apparently the kind of thing he does for fun, in his free time, when he's not already working full time with us programming Discourse. Programmers gotta … program.

Of course there's a long history of programming games. What makes TIS-100 unique is the way it fetishizes assembly programming, while most programming games take it a bit easier on you by easing you in with general concepts and simpler abstractions. But even "simple" programming games can be quite difficult. Consider one of my favorites on the Apple II, Rocky's Boots, and its sequel, Robot Odyssey. I loved this game, but in true programming fashion it was so difficult that finishing it in any meaningful sense was basically impossible:

Let me say: Any kid who completes this game while still a kid (I know only one, who also is one of the smartest programmers I’ve ever met) is guaranteed a career as a software engineer. Hell, any adult who can complete this game should go into engineering. Robot Odyssey is the hardest damn “educational” game ever made. It is also a stunning technical achievement, and one of the most innovative games of the Apple IIe era.

Visionary, absurdly difficult games such as this gain cult followings. It is the game I remember most from my childhood. It is the game I love (and despise) the most, because it was the hardest, the most complex, the most challenging. The world it presented was like being exposed to Plato’s forms, a secret, nonphysical realm of pure ideas and logic. The challenge of the game—and it was one serious challenge—was to understand that other world. Programmer Thomas Foote had just started college when he picked up the game: “I swore to myself,” he told me, “that as God is my witness, I would finish this game before I finished college. I managed to do it, but just barely.”

I was happy dinking around with a few robots that did a few things, got stuck, and moved on to other games. I got a little turned off by the way it treated programming as electrical engineering; messing around with a ton of AND OR and NOT gates was just not my jam. I was already cutting my teeth on BASIC by that point and I sensed a level of mastery was necessary here that I probably didn't have and I wasn't sure I even wanted.

I'll take a COBOL code listing over that monstrosity any day of the week. Perhaps Robot Odyssey was so hard because, in the end, it was a bare metal CPU programming simulation, like TIS-100.

A more gentle example of a modern programming game is Tomorrow Corporation's excellent Human Resource Machine.

It has exactly the irreverent sense of humor you'd expect from the studio that built World of Goo and Little Inferno, both excellent and highly recommendable games in their own right. If you've ever wanted to find out if someone is truly interested in programming, recommend this game to them and see. It starts with only 2 instructions and slowly widens to include 11. Corporate drudgery has never been so … er, fun?

I'm thinking about this because I believe there's a strong connection between programming games and being a talented software engineer. It's that essential sense of play, the idea that you're experimenting with this stuff because you enjoy it, and you bend it to your will out of the sheer joy of creation more than anything else. As I once said:

Joel implied that good programmers love programming so much they'd do it for no pay at all. I won't go quite that far, but I will note that the best programmers I've known have all had a lifelong passion for what they do. There's no way a minor economic blip would ever convince them they should do anything else. No way. No how.

I'd rather sit a potential hire in front of Human Resource Machine and time how long it takes them to work through a few levels than have them solve FizzBuzz for me on a whiteboard. Is this interview about demonstrating competency in a certain technical skill that's worth a certain amount of money, or showing me how you can improvise and have fun?

That's why I was so excited when Patrick, Thomas, and Erin founded Starfighter.

If you want to know how competent a programmer is, give them a real-ish simulation of a real-ish system to hack against and experiment with – and see how far they get. In security parlance, this is known as a CTF, as popularized by Defcon. But it's rarely extended to programming, until now. Their first simulation is StockFighter.

Participants are given:

• An interactive trading blotter interface
• A real, functioning set of limit-order-book venues
• A carefully documented JSON HTTP API, with an API explorer
• A series of programming missions.

Participants are asked to:

• Implement programmatic trading against a real exchange in a thickly traded market.
• Execute block-shopping trading strategies.
• Implement electronic market makers.
• Pull off an elaborate HFT trading heist.

This is a seriously next level hiring strategy, far beyond anything else I've seen out there. It's so next level that to be honest, I got really jealous reading about it, because I've felt for a long time that Stack Overflow should be doing yearly programming game events exactly like this, with special one-time badges obtainable only by completing certain levels on that particular year. Stack Overflow is already a sort of game, but people would go nuts for a yearly programming game event. Absolutely bonkers.

I know we've talked about giving lip service to the idea of hiring the best, but if that's really what you want to do, the best programmers I've ever known have excelled at exactly the situation that Starfighter simulates — live troubleshooting and reverse engineering of an existing system, even to the point of finding rare exploits.

Consider the dedication of this participant who built a complete wireless trading device for StockFighter. Was it necessary? Was it practical? No. It's the programming game we never asked for. But here we are, regardless.

An arbitrary programming game, particularly one that goes to great lengths to simulate a fictional system, is a wonderful expression of the inherent joy in playing and experimenting with code. If I could find them, I'd gladly hire a dozen people just like that any day, and set them loose on our very real programming project.

[advertisement] At Stack Overflow, we put developers first. We already help you find answers to your tough coding questions; now let us help you find your next job.

This week at Build 2016, we released Visual Studio 2015 Update 2 and Visual Studio “15” Preview. Both releases include many new language features that you can try today. It’s safe to install both versions of Visual Studio on the same machine so that you can check out all of the new features for yourself.

• Download Visual Studio Update 2
• Download Visual Studio “15” Preview

New C# and VB features in Visual Studio 2015 Update 2

In Visual Studio 2015 Update 2, you’ll notice that we’ve added some enhancements to previous features as well as added some new refactorings. The team focused on improving developer productivity by cutting down time, mouse-clicks, and keystrokes to make the actions you perform every day more efficient.

Interactive Improvements (C# only in Update 2, VB planned for future)

The C# Interactive window and command-line REPL, csi, were introduced in Visual Studio Update 1. In Update 2, we’ve paired the interactive experience with the editor by allowing developers to send code snippets from the editor to be executed in the Interactive window. We’ve also enabled developers to initialize the Interactive window with a project’s context.

To play with these features:

• Highlight a code snippet in the editor, right-click, and press Execute in Interactive (or Ctrl+E, Ctrl+E), as shown in the image below.
• Right-click on a project in the Solution Explorer and press Initialize Interactive with project.

Add Imports/Using Improvements (VB and C# in Update 2)

We’ve improved the Adding Imports/Using command to support “fuzzy” matching on misspelled types and to search your entire solution and metadata for the correct type—adding both a using/imports and any project/metadata references, if necessary.

You can see an example of this feature with a misspelled “WebCleint” type. The type name needs to be fixed (two letters are transposed) and the System.Net using needs to be added.

Refactorings

A couple refactorings we sprinkled in were:

• Make method synchronous (VB and C# in Update 2)
• Use null-conditional for delegate invocation (C# only in Update 2, Maybe for VB? – Read More below)

So, the killer scenario for this feature is raising events in a thread-safe way. Prior to C# 6 the proper way to do this was to copy the backing field of the event to a local variable, check the variable for null-ness and invoke the delegate inside the if. Otherwise Thread B could set the delegate to null by removing the last handler after Thread A has checked it for null resulting in Thread A unintentionally throwing a NullReferenceException. Using the null-conditional in C# is a much shorter form of this pattern. But in VB the RaiseEvent statement already raised the event in a null safe way, using the same code-gen. So the killer scenario for this refactoring really didn’t exist and worse, if we add the refactoring people might mistakenly change their code to be less idiomatic with no benefit. From time to time we review samples that don’t understand this and perform the null check explicitly anyway so this seems likely to reinforce that redundant behavior. Let us know in the comments if you think the refactoring still has tons of value for you outside of raising events and we’ll reconsider! -ADG

Roslyn Features (VB and C# in Update 2)

We’ve added two new compiler flags to the Roslyn compiler:

• deterministic: This switch will ensure builds with the same inputs produce the same the outputs, byte for byte. Previously, PE entries–like MVID, PDB ID and Timestamp–would change on every build but now can be calculated deterministically based on the inputs.
• publicSign: Supports a new method of signing that is similar to delay signing except it doesn’t need to add skip verification entries to your machine. Binaries can be public signed with only the public key and load into contexts necessary for development and testing. This is also known as OSS signing.

Sneak Peek: What’s in Visual Studio “15” Preview

We released a first look of Visual Studio “15” this week at Build. It is point in time view of what we’ve been working on. Some features will still change and others are still coming. It’s a good opportunity to provide feedback on the next big release of Visual Studio.

Play with C# 7 Prototypes (VB 15 Prototypes planned)

The guiding theme for C# 7 language design is “working with data”. While the final feature set for C# 7 is still being determined by the Language Design Committee, you can play with some of our language feature prototypes today in Visual Studio “15” Preview.

To access the language prototypes, right-click on your project in Solution Explorer > Properties > Build and type “__DEMO__” in the “Conditional compilation symbols” text box. This will enable you to play with a preview of local functions, digit separators, binary literals, ref returns, and pattern matching.

There is a known bug related to ref return IntelliSense, which can be worked around by:

• right-click on your project in Solution Explorer > Unload Project
• right-click on your project after it’s been unloaded > Edit csproj
• in the first Property Group under <AssemblyName> add: <Features>refLocalsAndReturns</Features>
• Ignore any XML schema warnings you may see

Custom Code Style Enforcement (VB and C# in Visual Studio “15” Preview)

The feature you all have been asking for is almost here! In Visual Studio “15” Preview, you can play around and give us feedback on our initial prototype for customizable code style enforcement. To see the style options we support today, go to Tools > Options > C#/VB > Code Style. Under the General options, you can tweak “this.”/”Me.”, predefined type, and “var”/type inference preferences. Today, with “var’ preferences, you can control the severity of enforcement—e.g., I can prefer “var” over explicit types for built-in types and make any violation of this squiggle as an error in the editor.

You can also add Naming rules, for instance, to require methods to be PascalCase.

Please Keep up the Feedback

Thanks for all the feedback we’ve received over the last year. It’s had a big impact on the features that I’ve described here and on others we’ve been working on. Please keep it coming. The language feedback on the open source Roslyn project has been extensive. It’s great to see a broader language community developing around the Roslyn open source project on Github.

To give feedback, try one of the following places:

• The Roslyn project, for language feedback
• Send Feedback Option Visual Studio, for Visual Studio feedback
• UserVoice , for Visual Studio suggestions

Thanks for using the product. I hope you enjoy using it to build your next app.

Over ‘n’ out
Kasey Uhlenhuth, Program Manager, Managed Languages Team

La startup toulousaine Sigfox et Microsoft annoncent l’intégration du cloud Sigfox à la plateforme Azure IoT Hub de Microsoft en France.