Scott Hanselman

ASP.NET and Web Tools 2012.2 (Release Candidate)

December 13, '12 Comments [52] Posted in ASP.NET | ASP.NET Ajax | ASP.NET Dynamic Data | ASP.NET MVC | ASP.NET Web API
Sponsored By

All the parts of ASP.NET, all the subsystems are all part of the larger ASP.NET communityI've talked before in presentations that the ASP.NET and Web Tools team has been slowly externalizing pieces of ASP.NET. You've seen it in many pieces of the ASP.NET runtime moving into NuGet while also being open sourced, and you've seen it as we've moved big chunks of the "tooling" (that means the menus and dialogs you interact within Visual Studio when using ASP.NET) into external installers.

Why are we doing this? Because the Web moves faster than Visual Studio does. We want to be able to offer a stable ASP.NET core that you can count on while being able to offer new and powerful features more often as needed.

Visual Studio itself has moved to a faster update model and recently released Visual Studio 2012.1 (that's Visual Studio 2012 Update 1 if you prefer.) You can get the VS2012.1 update here or just wait for Visual Studio to popup some toast and let you know.

We're going to release an update to ASP.NET we'll call ASP.NET and Web Tools 2012.2. This will happen early next year but today you can download our Release Candidate! You can watch my presentation with Jon Galloway from the BUILD conference or read the release notes. This RC is, of course, newer than the one we released at BUILD and has a better name.

This is a tooling refresh of Visual Studio 2012 and extends the existing run time with new features without breaking existing applications. This adds new templates and features including:

  • Enhancements to Web Publishing unifying Web Application and Website project publish experience.  Selective publish, local/remote diffs and more.
  • Page Inspector has enhancements including JavaScript selection mapping and ability to see CSS updates in real-time.
  • New Web API functionality including support for OData, tracing and generating a help page for your API.
  • New MVC templates
    • You can create Facebook apps using the MVC Facebook template. In just a few easy steps you can create a Facebook Canvas Application that gets data from the logged in user as well and with friends.
    • The return and refresh of an all-new Single Page Application template allows developers to build interactive web apps using Knockout JavaScript library and a RESTful Web API.
  • Real-time communication via SignalR. This means SignalR, in case you haven't heard, is a real and official thing. It's fully supported by Microsoft.
  • Extensionless Web Forms via ASP.NET Friendly URLs which makes it easy for web forms developers to generate clean URLs without the .aspx extension. This can be used with existing ASP.NET 4.0 applications as well!
    • FriendlyURLs also makes it easier for developers to add mobile support to their applications, by supporting switching between desktop and mobile views.
  • Editor support for Knockout IntelliSense and pasting JSON as a class.

ASP.NET and Web Tools 2012.2 installs quickly and does NOT alter the current ASP.NET run time components or change the GAC. For a complete description see the Release Notes.

ASP.NET Fall 2012 Update for Visual Studio 2012 can be installed from the Fall 2012 Update home page(http://www.asp.net/vnext/overview/fall-2012-update). This is an update to Visual Studio 2012, which is required. This Release Candidate update does not support localized versions yet.  You see the new features in English but we'll will have localization support in upcoming RTM. It is an RC so there are some known issues. Be sure to check out the Release Notes for issues and workarounds.

Also be sure to get our "labs" component for Web Developers called Web Essentials. This is a place for Mads and the team to try out new features and play. When those features are baked, we'll graduate them to an update like this one!

Why isn't this called ASP.NET 4.6? Because it's not. The GAC'ed ASP.NET 4.5 doesn't change. This is mostly a tooling update as well as a collection of NuGet-based libraries that augment but don't replace ASP.NET 4.5. If we called if ASP.NET 4.6 then folks would think they needed to rush to update their servers. They don't. It's an update for "Web Tools for VS 2012" but that's lame, so since we got the VS guys to use the .1, .2, .3 scheme rather than September Update CTP Refresh, then we can make things easier by calling this Web Tools 2012.2.

This .2 release is just a step towards a more componentized "One ASP.NET." I hope you enjoy the direction we're heading. We've got some new things planned like a unified "File New ASP.NET Application" dialog, a better way to add your own templates and share them with the community, and a more level playing field for everyone.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Comparing two techniques in .NET Asynchronous Coordination Primitives

December 11, '12 Comments [13] Posted in Back to Basics | Learning .NET
Sponsored By

Last week in my post on updating my Windows Phone 7 application to Windows 8 I shared some code from Michael L. Perry using a concept whereby one protects access to a shared resource using a critical section in a way that works comfortably with the new await/async keywords. Protecting shared resources like files is a little more subtle now that asynchronous is so easy. We'll see this more and more as Windows 8 and Windows Phone 8 promote the idea that apps shouldn't block for anything.

After that post, my friend and mentor (he doesn't know he's my mentor but I just decided that he is just now) Stephen Toub, expert on all things asynchronous, sent me an email with some excellent thoughts and feedback on this technique. I include some of that email here with permission as it will help us all learn!

I hadn’t seen the Awaitable Critical Section helper you mention below before, but I just took a look at it, and while it’s functional, it’s not ideal.  For a client-side solution like this, it’s probably fine.  If this were a server-side solution, though, I’d be concerned about the overhead associated with this particular implementation.

I love Stephen Toubs's feedback in all things. Always firm but kind. Stephen Cleary makes a similar observation in the comments and also points out that immediately disabling the button works too. ;) It's also worth noting that Cleary's excellent AsyncEx library has lots of async-ready primitives and supports both Windows Phone 8 and 7.5.

The SemaphoreSlim class was updated on .NET 4.5 (and Windows Phone 8) to support async waits. You would have to build your own IDisposable Release, though. (In the situation you describe, I usually just disable the button at the beginning of the async handler and re-enable it at the end; but async synchronization would work too).

Ultimately what we're trying to do is create "Async Coordination Primitives" and Toub talked about this in February.

Here's in layman's terms what we're trying to do, why it's interesting and a definition of a Coordinate Primitive (stolen from MSDN):

Asynchronous programming is hard because there is no simple method to coordinate between multiple operations, deal with partial failure (one of many operations fail but others succeed) and also define execution behavior of asynchronous callbacks, so they don't violate some concurrency constraint. For example, they don't attempt to do something in parallel. [Coordination Primitives] enable and promote concurrency by providing ways to express what coordination should happen.

In this case, we're trying to handled locking when using async, which is just one kind of coordination primitive. From Stephen Toub's blog:

Here, we’ll look at building support for an async mutual exclusion mechanism that supports scoping via ‘using.’

I previously blogged about a similar solution (http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/10266988.aspx), which would result in a helper class like this:

Here Toub uses the new lightweight SemaphoreSlim class and indulges our love of the "using" pattern to create something very lightweight.

public sealed class AsyncLock
{
private readonly SemaphoreSlim m_semaphore = new SemaphoreSlim(1, 1);
private readonly Task<IDisposable> m_releaser;

public AsyncLock()
{
m_releaser = Task.FromResult((IDisposable)new Releaser(this));
}

public Task<IDisposable> LockAsync()
{
var wait = m_semaphore.WaitAsync();
return wait.IsCompleted ?
m_releaser :
wait.ContinueWith((_, state) => (IDisposable)state,
m_releaser.Result, CancellationToken.None,
TaskContinuationOptions.ExecuteSynchronously, TaskScheduler.Default);
}

private sealed class Releaser : IDisposable
{
private readonly AsyncLock m_toRelease;
internal Releaser(AsyncLock toRelease) { m_toRelease = toRelease; }
public void Dispose() { m_toRelease.m_semaphore.Release(); }
}
}

How lightweight and how is this different from the previous solution? Here's Stephen Toub, emphasis mine.

There are a few reasons I’m not enamored with the referenced AwaitableCriticalSection solution. 

First, it has unnecessary allocations; again, not a big deal for a client library, but potentially more impactful for a server-side solution.  An example of this is that often with locks, when you access them they’re uncontended, and in such cases you really want acquiring and releasing the lock to be as low-overhead as possible; in other words, accessing uncontended locks should involve a fast path.  With AsyncLock above, you can see that on the fast path where the task we get back from WaitAsync is already completed, we’re just returning a cached already-completed task, so there’s no allocation (for the uncontended path where there’s still count left in the semaphore, WaitAsync will use a similar trick and will not incur any allocations).

Lots here to parse. One of the interesting meta-points is that a simple client-side app with a user interacting (like my app) has VERY different behaviors than a high-throughput server-side application. Translation? I can get away with a lot more on the client side...but should I when I don't have to?

His solution requires fewer allocations and zero garbage collections.

Overall, it’s also just much more unnecessary overhead.  A basic microbenchmark shows that in the uncontended case, AsyncLock above is about 30x faster with 0 GCs (versus a bunch of GCs in the AwaitableCriticalSection example.  And in the contended case, it looks to be about 10-15x faster.

Here's the microbenchmark comparing the two...remembering of course there's, "lies, damned lies, and microbenchmarks," but this one is pretty useful. ;)

class Program
{
static void Main()
{
const int ITERS = 100000;
while (true)
{
Run("Uncontended AL ", () => TestAsyncLockAsync(ITERS, false));
Run("Uncontended ACS", () => TestAwaitableCriticalSectionAsync(ITERS, false));
Run("Contended AL ", () => TestAsyncLockAsync(ITERS, true));
Run("Contended ACS", () => TestAwaitableCriticalSectionAsync(ITERS, true));
Console.WriteLine();
}
}

static void Run(string name, Func<Task> test)
{
var sw = Stopwatch.StartNew();
test().Wait();
sw.Stop();
Console.WriteLine("{0}: {1}", name, sw.ElapsedMilliseconds);
}

static async Task TestAsyncLockAsync(int iters, bool contended)
{
var mutex = new AsyncLock();
if (contended)
{
var waits = new Task<IDisposable>[iters];
using (await mutex.LockAsync())
for (int i = 0; i < iters; i++)
waits[i] = mutex.LockAsync();
for (int i = 0; i < iters; i++)
using (await waits[i]) { }
}
else
{
for (int i = 0; i < iters; i++)
using (await mutex.LockAsync()) { }
}
}

static async Task TestAwaitableCriticalSectionAsync(int iters, bool contended)
{
var mutex = new AwaitableCriticalSection();
if (contended)
{
var waits = new Task<IDisposable>[iters];
using (await mutex.EnterAsync())
for (int i = 0; i < iters; i++)
waits[i] = mutex.EnterAsync();
for (int i = 0; i < iters; i++)
using (await waits[i]) { }
}
else
{
for (int i = 0; i < iters; i++)
using (await mutex.EnterAsync()) { }
}
}
}

Stephen Toub is using Semaphore Slim, the "lightest weight" option available, rather than RegisterWaitForSingleObject:

Second, and more importantly, the AwaitableCriticalSection is using a fairly heavy synchronization mechanism to provide the mutual exclusion.  The solution is using Task.Factory.FromAsync(IAsyncResult, …), which is just a wrapper around ThreadPool.RegisterWaitForSingleObject (see http://blogs.msdn.com/b/pfxteam/archive/2012/02/06/10264610.aspx).  Each call to this is asking the ThreadPool to have a thread block waiting on the supplied ManualResetEvent, and then to complete the returned Task when the event is set.  Thankfully, the ThreadPool doesn’t burn one thread per event, and rather groups multiple events together per thread, but still, you end up wasting some number of threads (IIRC, it’s 63 events per thread), so in a server-side environment, this could result in degraded behavior.

All in all, a education for me - and I hope you, Dear Reader - as well as a few important lessons.

  • Know what's happening underneath if you can.
  • Code Reviews are always a good thing.
  • Ask someone smarter.
  • Performance may not matter in one context but it can in another.
  • You can likely get away with this or that, until you totally can't. (Client vs. Server)

Thanks Stephen Toub and Stephen Cleary!

Related Reading

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Updating my Windows Phone App to Windows Phone 8

December 8, '12 Comments [18] Posted in WinPhone
Sponsored By

Lost Phone Screen on Windows Phone 8Earlier this year I wrote a small Windows Phone 7 application in a day called Lost Phone Screen. It creates lock screens for you with your name and contact number on them to aid in finding your phone the old fashioned way when you lose it. No need for a GPS, just tell folks you have a small reward and give them a number to call. You can download it free now as folks will not pay 99 cents for anything except Angry Birds. But I'm not bitter. ;) Anyway, it works great on Windows Phone 7 and Windows Phone 7.5 (Mango.)

Recently I got a Nokia Lumia 920 with Windows Phone 8 and since there's a number of new APIs and features I could exploit - not the least of which being the ability to programmatically set the phone's Lock Screen without the user needing to do anything - I figured it was time to update it.

I encourage you to review the post From Concept to Code in 6 hours: Shipping my first Windows Phone App as a reminder of what the app did and the issues I had writing the Windows Phone 7.x version.

Here's what I had to think about updating the app for Windows Phone 8. Big thanks to my friend Justin Angel at Nokia for brainstorming on Skype with me and helping with the async code and resolution issues. His blog post on What's New in Windows Phone 8 was very useful, especially his little MultiRes helper class.

Updating The App

First, to be clear, the existing Windows Phone 7 app works great on Windows Phone 8 without ANY changes. It runs and behaves exactly on Windows Phone 8 as it did on Windows Phone 7. I wanted to update it in order to "light up" some the new features on the new OS.

Upgrading the Project to Windows Phone 8

Upgrading was easy, I opened the old project and was prompted to upgrade. I double-clicked on the WMAppManifest.xml and made sure to reassert some of the basic settings like icon sizes and tiles for my app, as well as confirming the capabilities that my app would need like photo access, etc.

I was sure to check the Supported Resolutions as I knew I'd need those later.

Windows Phone 8 supports three resolutions

Keeping two Branches vs. One Super Project

I went back and forth on this. It's an upgraded OS but 99% of the code will be shared. However, enough stuff has changed that I decided to make a branch in source control rather than make a single build. Honestly, there's likely no wrong answer here and you use what you're comfortable with. I could have to CSProj files if I liked, or just made a different Build Configuration (like Debug8 and Debug7, etc) but I understand my source control pretty well so I ended up with a phone70 and a phone80 branch and I switch between them. It's more likely that I'll be updating the phone80 branch then "back porting" new feature so for now this work fine, but know I can always make a single build if I want.

Ultimately though, I know that I need to make a build for Windows Phone 7.x and one for Windows Phone 8 but I can submit them each to the Store under the same name and the Store will do the right thing. If you've got Windows Phone 8 with a new resolution you'll get the right version as you can see in the screenshot below. I've submitted two XAP files.

Two versions of the same app in the Store, one for each phone

New Screen Resolutions

I updated my app a few weeks ago but my first good bug came in from a gent with a HTC Windows Phone device running at 1280x720, rather than 1280x768. He said my lockscreens were cropped! With Windows Phone 8 there's three resolutions, in fact as Justin points out:

The resolutions are: WVGA (480x800 pixels), also used in Windows Phone 7; WXGA (768x1280 pixels), essentially an HD version of WVGA; and the wildcard 720P (720x1280 pixels) that uses a different aspect ratio to WVGA and WXGA. You should be aware of these different resolutions, make sure to use relative <Grid /> positioning in laying out screens, and potentially different media assets for different resolutions.

It's less important that there's three resolutions but rather more interesting that 720p is a different aspect ratio! Turns out I was making a number of assumptions in my code, not the least of which being the screen resolution. I was assuming 15:9 as the aspect ratio like 800x480 and 1280x768, but 16:9 is 1280x720!

My initial reaction was, crap, now I have to actually think.

Turns out that it's easier than that. On all of my app's pages but one I was able to remove XAML code and hard coded margins and row definitions. I was actually being too specific and not letting the system lay itself out optimally.

I removed all my hard-coded margins and changed my Grids to use a RowDefinition of "*" which means "the rest of the space" like this:

<Grid x:Name="LayoutRoot" Background="Transparent">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
...
</Grid>

The first RowDefinition fills to the size of its content and the second just takes up the rest. This made all my pages look great on every resolution screen, and it was easy to test because I could just change the Emulator dropdown to select the various  resolutions:

Different Emulator Resolutions in a Dropdown

However, with these new resolutions, I did change my originally single SplashScreenImage.jpg to include one each for the three resolutions named SplashScreenImage.Screen-720p.jpg, SplashScreenImage.Screen-WVGA.jpg and SplashScreenImage.Screen-WXGA.jpg. You'll find that at least half your time doing mobile apps (regardless of Apple, Windows or Android) is getting the PNGs and artwork files correct).

Three new SplashScreens

I had (chose) to hard code some screen sizes in one place in the app. (I could have queried  Application.Current.Host.Content.ScaleFactor. Application.Current.Host.Content.ActualHeight and Application.Current.Host.Content.ActualWidth to be correct.) I have a VERY specific custom Image Cropping control that needed special handling for the 720p case, likely due to my lack of skill with XAML. I am told that only the most edgy of edge cases need to do this and often this is in the creation of pixel-perfect lock screens so you probably won't sweat it at all.

New Lock Screen API

Finally my app can update the Lock Screen without manual user intervention. This was my #1 request and everyone assumed it was my fault that the feature didn't exist. It's been added in Windows Phone 8.

If you app wants to change the Lock Screen it has to ask once and get permission. It has to be the "current lock screen provider." If it is, it requests access and then sets the lock screen.

if (!LockScreenManager.IsProvidedByCurrentApplication)
{
LockScreenRequestResult result = await LockScreenManager.RequestAccessAsync();
if (result == LockScreenRequestResult.Granted)
{
SetAsWallpaper(filename);
}
}
else
{
SetAsWallpaper(filename);
}

SetAsWallpaper is just a helper around LockScreen.SetImageUri().

private void SetAsWallpaper(string filename)
{
string realPath = "ms-appdata:///local/" + filename;
Debug.WriteLine(realPath);
//Debug.WriteLine(ApplicationData.Current.LocalFolder.Path);

LockScreen.SetImageUri(new Uri(realPath, UriKind.Absolute));
}

And that's it. Lovely and simple. BUT.

A Very Important Reminder when using Asynchronous APIs

In Windows 8 and Windows Phone 8 (since the Windows 8 magic dust is under Windows Phone 8) everything is all about asynchrony and non-blocking APIs. Before I'd just save the wallpaper and you'd wait and you had no choice. Now all the underlying APIs are asynchronous  (non-blocking) and we as developers have await/async keywords to make things simple, right?

Sure, but my second lovely bug that showed up was when folks mashed on the Save button many times. Because everything is non-blocking this would fire off many save requests and eventually they'd collide at the file system with an "Access Denied" or something equally useful.

I have this shared resource that I need to protect access to but I don't want to block the UI. Michael L Perry has a great solution for this that should probably be built into the Windows Phone SDK (unless it is and we've all missed it?) in his Awaitable Critical Section helper. This helper lets us use the familiar using{} block structure in situations where we are using async and await inside what would have been a lock(){} block.

As Michael points out, you CAN'T do this because you can't await in a lock.

lock (this)
{
FileHandle file = await FileHandle.OpenAsync();
await file.WriteAsync(value);
file.Close();
}

But with his helper you can do this:

using (var section = await _criticalSection.EnterAsync())
{
FileHandle file = await FileHandle.OpenAsync();
await file.WriteAsync(value);
file.Close();
}

And I did just that.

Analyze

When you're done, make sure you run the Windows Phone Application Analysis tools see how your application does. Does it use too much memory? Use up the battery? Does it startup in less than a second?

Windows Phone Application Analysis

This is fascinating stuff. Don't work so hard on your app and forget to profile it.

New Things to Remember when Submitting Your App and Submitting Two Versions

I fixed some bugs in the Windows Phone 7 version, changed that XAP's version number and submitted it as a small upgrade. Folks who have Windows Phone 7.x will get prompted to update their app. This version, as you'll recall, doesn't auto-update the lock screen because it can't.

I go into the Phone Marketplace and click Update App from the Dashboard. There's the Marketplace before my update, showing the 7.1 app:

Windows Phone 7 app

I click Update selected and upload the new Windows Phone 7.1 targeted XAP that I just built. After that's uploaded I change the dropdown and upload the Windows Phone 8 XAP. I make sure in both cases to upload a Release XAP and the "AnyCPU" version.

Windows Phone 8 app

I am keeping the Windows Phone 8 one a few versions ahead for my own sanity. It makes sense to me and it helps me remember what's "newest" even though it only matters that the new versions be higher than the previous versions.

Be sure to check all your text, your descriptions and icons to make sure they are correct.

Time Spend Coding vs. Time Spend Editing PNGs

Goodness, I swear I have spent more time messing with screenshots and PNGs than coding.

Here's the thing: Mobile app development is all about the Screenshots and Icons.

There's so many resolutions and assets and different scenarios where your application can be showcased that it's worth spending some time getting really good at PhotoShop or Paint.NET. I'm doing all my work in Paint.NET, in fact.

Because there's three resolutions you'll want to make note that you need three sets of screenshots! Fortunately there's a screenshot cool built into the Emulator and Windows Phone also supports in-device screenshots (finally) by pressing Power+Windows Key.

It may not be obvious from this picture of the marketplace submission but you need to click WXGA and 720p and upload separate screenshots for each one! Otherwise your potential users won't see your app looking exactly as it will on their device. Tedious, but crucial.

Three sets of screenshots for three resolutions

Truly, this became an asset management chore. I ended up with a folder fill of JPGs and PNGs and only kept my sanity with some reasonable file name conventions.

naming screenshots and splashscreens reasonably.

You will end up with at least 24 screenshots (3x8) plus three splash screens, several icon sizes and you'll also want to test on both the Dark and Light themes.

Conclusion

In the end, it will be seamless for your end users. Folks who have Windows Phone 8 will get their updates from your WP8-XAP and Windows Phone 7.x folks will get theirs from your WP7-built XAP. This whole thing took about 3 hours and most of that time was spent doing screenshots.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

My next PC will be an Ultrabook

December 4, '12 Comments [114] Posted in Reviews
Sponsored By

Darn it all. I didn't want to like this little computer. I've always been a "MOAR POWER" laptop user. For me, laptops are desktop replacements. It's less about the carrying and more about the "setting up in a remote place and having all the power of your desktop." My main laptop has been a Lenovo W520 for years. It's got dual SSDs, 8 (logical) processors and 16 gigs of RAM.

But lately I haven't even turned it on. I have a MacBook Pro but it also goes unused. I've been using this little Intel Ultrabook prototype near-exclusively for months and I've gotten to the point where I've decided that my next machine will be ultralight.

The Good

  • You really can get good power and responsiveness out of a 3lb machine.
  • Don't knock a touchscreen until you've used one. Every laptop should (and will) have a touch screen in a year. Mark my words. This nonsense about how your arm will hurt assumes that you're only using it. A touchscreen is complementary not primary. I use it for pinching, for scrolling web pages, and for launching apps. It's much faster to just touch the icon than to mouse over to click one.
  • Not thinking about memory. I am shocked but I have only 4 gigs of RAM on this machine. I didn't think that would be enough to get anything done. However, I've been able to run Hyper-V VMs, do Windows Phone 8 development, run multiple copies of Visual Studio along with Outlook and have had no problems. I think that a fast SSD along with a fast processor as well as an OS that manages memory more aggressively (Windows 8) adds up to a situation where anything around 4 gigs is sufficient, even for me.

The Bad

  • Flaky drivers. As I said, I'm using a hardware prototype but the drivers for this device are flaky. The WiFi and WebCam are both goofy and a little unreliable. I'm not worried about it and neither have really caused me any trouble other than a reboot twice a week.
  • Mini HDMI. I find the lack of a proper VGA port to be irritating and mini HDMI just isn't physically strong enough to support the dongles I need for presenting and I am always worried I'll one day break the port.

That's about it. Otherwise my experience with an Ultrabook has been rock solid.

Two of the machines I'm looking at getting are one of these.

The Acer S7. Small, light, touchscreen, backlit keyboard, cool on the lap.

S7-Benefit-images-1

The Lenovo Ideapad Yoga. It has a hinge that supports a use as regular laptop, a tablet, a stand (or as a "tent") for movies on a plane or presentations. I'm leaning in this direction.

ideapad-lenovo-ideapad-yoga-13,P-X-356037-13

I'll want to get an i7 rather than an i5 processor. If possible I will want a 1080p display, so I'm hoping the Yoga adds screen resolution, although, I've been running 1600x900 on this Intel and it seems OK. I just like the idea of 1080p and True HD.

The Surface Pro (with Type Cover). The Touch Cover is cute, but I want a laptop more than I want a tablet. This device has the benefits of being a 1080p screen, runs all my Windows apps. It's an i5 which gives me pause, although it's only 2 lbs.

3286.Surface_Pro.jpg-550x0

What Ultrabooks are you looking at?

Related Links

Disclosure of Material Connection: Intel sent me this Ultrabook for free in the hope that I would review it on my blog. Regardless, I only recommend products or services I I would use and think you would find useful. I am disclosing this in accordance with the Federal Trade Commission’s 16 CFR, Part 255: “Guides Concerning the Use of Endorsements and Testimonials in Advertising.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Nest Thermostat Review 2nd Generation - Every consumer electronic device should be this polished

November 25, '12 Comments [75] Posted in Reviews
Sponsored By

Nest in the boxLast year I purchased and installed a 3M Filtrete Touchscreen WiFi-Enabled Programmable Thermostat and have generally been very happy with it. It's not automatic, but it's programmable and it has a remote control iPhone app and a very nice programmable web API. Since I work at home, sometimes I am in my home office and other times I'm in a local coffee shop, and in these instances I just use the phone to turn off heat as I leave.

More recently I've been hearing about the Nest Learning Thermostat. There are two generations, Nest Gen 1 and Nest Gen 2 which is 20% thinner than the first Nest and includes support for 95% of North American heating and cooling systems.

I saved up and bought one. It's great.

OOBE - Out of Box Experience

When you spend $200 or more on a Thermostat you're expecting to be impressed. The entire experience from unboxing through installation and usage is absolutely top notch. There's an online Nest Compatibility Tool you can use to check if you've got the right wires for Nest to work with your heating and cooling system. If that doesn't cut it, you are invited to take picture (!) of your setup and send it to them. Classy.

Unboxing the Nest, just like unboxing an iPhone HAL from 2001: Space Odyssey

Unboxing it is like unboxing an iPhone or high end receiver. It's like unboxing HAL from 2001: A Space Odyssey, in fact, which is pretty awesome.

Installation

The box includes every piece of hardware you could need. Even the tiny screwdriver they included is brilliant. It's got 4 magnetic tips and it's become my favorite screwdriver for small computer stuff and I've taken to keeping it on my desk. It may seem a small thing, but think about that for a second. Someone decided to make and ship an awesome screwdriver. I love that.

There's a rectangular back plate included that can be used to cover holes from your previous installation.

All the things that come with your Nest. The Nest itself, the wallplates, instructions and screwdriver Checking out the amazing tiny screwdriver the Nest guys included

I went back and forth about using the back plate and came to the conclusion that a thermostat this fancy deserved a few hours of extra effort. I could have slapped the back plate on the wall and been done in minutes but instead I took a little bit of putty/spackle, filled the holes left from the previous thermostat and painted with a small modeler's paintbrush.

Take the Time and Paint

I am EXTREMELY happy and a more than little proud of the results.

Removing the original thermostat Puttying over the holes

Painting over the puttied holes Adding the Nest round cover

Connect the Network

You snap the Nest onto the round backing and it immediately turns on. You rotate the Nest's outer ring to make selections and you press in to make a selection. My Nest needed to update itself and apparently Nests will auto-update without you having to do anything but wait a bit.

IMG_2494 IMG_2495

The Good (there's been Zero Bad)

The Nest tells me it will get 72 degrees in 15 minutesI've had the Nest for a few weeks now and while I can't tell if it's saved me a pile of money yet, I can note a number of significant things that have made a difference to me and the family.

  • I've had to fiddle with the Nest much LESS than my previous wireless thermostat. We used to adjust the Filtrete a few times a day. I had created a schedule but it couldn't handle how I'd leave sometimes at random.
  • My wife gets it more than the previous thermostat because it's extremely simple. The Filtrete required several button pushes to change the temperature and the scheduler was circa a 1900s LCD VCR.
  • The auto-away feature is almost worth the price of admission. Our thermostat is located in our Family Room near the door we use to enter and exit the house. Auto-away works fantastically and exactly as you'd think it should.
  • The Nest is dark until you walk up to it. It turns on the display literally as you approach. It's fun to walk by it.
  • It tells you how long it will take for the house to reach a certain temperature because it learns how long your house takes to move temperatures. My wife used to turn the thermostat really hot because she thought that if she set it to 80 then it would get to 72 faster. The Nest solves that problem by telling her it will reach 72F in 15 minutes.

The Nest app is as well-designed as the Next, or more so. The Nest is simple and hides complexity but if you go digging and WANT to see what the underbelly looks like, it hides little. You can get details on the wiring - now hidden physically but visible virtually.

You can see the schedule that the Nest automatically gleaned based on yours and your family's behaviors. For the first week you are asked to adjust the Nest as much as you like in order to teach it about your preferences. It uses this data, combined with local weather and noticing if you leave to build a schedule. It also overrides that schedule liberally using auto-away.

Screenshot of the Nest App showing wiring Screenshot of the Nest App showing Heat/Cool

The Nest is kind of the Prius of home thermostats, and I say that as a happy Prius owner. It make saving (or trying to save) energy a game. It'll show a leaf when you are choosing temperatures that can save energy. In the fourth screenshot you can see an icon on Thursday that indicated that I adjusted it manually and caused an energy savings. On Tues the weather was warmer than expected and caused the Nest to save energy.

Screenshot of the Nest App showing Schedule Screenshot of the Nest App showing Energy

You can zoom in on any of these graphs and get LOTS of details. You can see here that I left for lunch at Noon on Friday.

Nest noticed that I went to lunch and adjusted the temperature Wednesday was a complex day

The best thing about the Nest. It's simple and its simplicity hides enormous complexity. It's a luxury item, to be sure, but it's a joy to use. I'm impressed and I suspect that when a Nest is $100 at Home Depot that they'll own the market.

I'll update the post in a few months when I have several heating bills.


PLUG: My friend Luvvie and I talk about the Nest in Episode 2 of our new bi-weekly Podcast, "Ratchet and The Geek." Check it out!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.