Scott Hanselman

I was reminded by a friend to explore WallabyJS this week. I had looked at WallabyJS a while back when it was less mature but I hadn't installed a more recent version. WOW. It's coming along nicely and is super-powerful. You should check it out if you write JavaScript. It's also super fast, for these reasons:

Wallaby.js is insanely fast, because it only executes tests affected by your code changes and runs your tests in parallel.

WallabyJS has plugins for the IntelliJ platform, Visual Studio, Atom, and more recently, there's preview support for Visual Studio Code and Sublime Text support is coming soon.

It supports supports TypeScript, CoffeeScript, and ES7. Wallaby supports jasmine for running tests but you can plug in your own testing framework and assertion library as you like.

Installing WallabyJS for Visual Studio Code is very easy now that Code supports extensions.

Once you've installed the extension it will download what's needed and bootstrap WallabyJS. I did have a small issue installing, but and uninstall/reinstall fixed it, so it may have been just a blip.

If you want to see it in action quickly without much setup, just clone their Calculator sample at

git clone https://github.com/wallabyjs/calculator-sample.git

Do note that it's not totally obvious once you've installed WallabyJS that you have to "start" its server manually...for now.

Once it has started, it's mostly automatic and runs tests as you type and save. You can access all WallabyJS's commands with hotkeys or from the Visual Studio Code command palette.

It's great to see a powerful tool like this working in Visual Studio Code. Remember you can get VSCode (now open source!) for any platform here code.visualstudio.com and you can get WallabyJS at their main site.

Sponsor: Big thanks to my friends at Redgate for sponsoring the feed this week.Check out their amazing FREE eBook! Discover 52 tips to improve your .NET performance: Our new eBook features dozens of tips and tricks to boost .NET performance. With contributions from .NET experts around the world, you’ll have a faster app in no time. Download your free copy.

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.

About   Newsletter

Hosting By

This post is neither a rant nor a complaint, but rather, an observation.

There's some amazing work happening over in the C#-based Kestrel web server. This is an little open source webserver that (currently) sits on libuv and lets you run ASP.NET web applications on Windows, Mac, or Linux. It was started by Louis DeJardin but more recently Ben Adams from Illyriad Games has become a primary committer, and obsessive optimizer.

Kestrel is now doing 1.2 MILLION requests a second on benchmarking hardware (all published at https://github.com/aspnet/benchmarks) and it's written in C#. There's some amazing stuff going on in the code base with various micro-optimizations that management memory more intelligently.

. @ben_a_adams I think it's safe to say you're on to something in that PR pic.twitter.com/ELIyxhYyun

— Damian Edwards (@DamianEdwards) December 23, 2015

Here's my question to you, Dear Reader, and I realize it will differ based on your language of choice:

When did you stop caring about Memory Management, and is that a bad thing?

When I started school, although I had poked around in BASIC a bit, I learned x86 Assembler first, then C, then Java. We were taught intense memory management and learned on things like Minix, writing device drivers, before moving up the stack to garbage collected languages. Many years later I wrote a tiny operating system simulator in C# that simulated virtual memory vs physical memory, page faults, etc.

There's a great reference here at Ravenbook (within their Memory Pool System docs) that lists popular languages and their memory management strategies. Let me pull this bit out about the C language:

The [C] language is notorious for fostering memory management bugs, including:

1. Accessing arrays with indexes that are out of bounds;
2. Using stack-allocated structures beyond their lifetimes (see use after free);
3. Using heap-allocated structures after freeing them (see use after free);
4. Neglecting to free heap-allocated objects when they are no longer required (see memory leak);
5. Failing to allocate memory for a pointer before using it;
6. Allocating insufficient memory for the intended contents;
7. Loading from allocated memory before storing into it;
8. Dereferencing non-pointers as if they were pointers.

When was the last time you thought about these things, assuming you're an application developer?

I've met and spoken to a number of application developers who have never thought about memory management in 10 and 15 year long careers. Java and C# and other languages have completely hidden this aspect of software from them.

BUT.

They have performance issues. They don't profile their applications. And sometimes, just sometimes, they struggle to find out why their application is slow.

My buddy Glenn Condron says you don't have to think about memory management until you totally have to think about memory management. He says "time spent sweating memory is time you're not writing your app. The hard part is developing the experience is that you need to know when you need to care."

I've talked about this a little in podcasts like the This Developer's Life episode on Abstractions with guests like Ward Cunningham, Charles Petzold, and Dan Bricklin as well as this post called Please Learn to Think about Abstractions.

How low should we go? How useful is it to know about C-style memory management when you're a front-end JavaScript Developer? Should we make it functional then make it fast...but if it's fast enough, then just make it work? The tragedy here is that if it "works on my machine" then the developer never goes back to tighten the screws.

I propose it IS important but I also think it's important to know how a differential gear works, but that's a "because" argument. What do you think?

Sponsor: Big thanks to Infragistics for sponsoring the blog this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

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.

About   Newsletter

Hosting By

A reader emailed asking how to avoid accidentally checking in passwords and other sensitive data into GitHub or source control in general. I think it's fair to say that we've all done this once or twice - it's a rite of passage for developers old and new.

The simplest way to avoid checking in passwords and/or connection strings into source control is to (no joke) keep passwords and connection strings out of your source.

Sounds condescending or funny, but it's not, it's true. You can't check in what doesn't exist on disk.

That said, sometimes you just need to mark a file as "ignored," meaning it's not under source control. For some systems that involves externalizing configuration values that may be in shared config files with a bunch of non-sensitive config data.

ASP.NET 4.6 secrets and connection strings

Just to be clear, how "secret" something is is up to you. If it's truly cryptographically secret or something like a private key, you should be looking at data protection systems or a Key Vault like Azure Key Vault. Here we are talking about medium business impact web apps with API keys for 3rd party web APIs and connection strings that can live in memory for short periods. Be smart.

ASP.NET 4.6 has web.config XML files like this with name/value pairs.

<appSettings>      
    <add key="name" value="someValue" />
    <add key="name" value="someSECRETValue" />
</appSettings>      

We don't want secrets in there! Instead, move them out like this:

<appSettings file="Web.SECRETS.config">      
    <add key="name" value="someValue" />
</appSettings>

Then you just put another appSettings section in that web.secrets.config file and it gets merged at runtime.

NOTE: It's worth pointing out that the AppSettings technique also works for Console apps with an app.config.

Finally, be sure to add Web.secrets.config (or, even better, make it *.secrets and use a unique extension to identify your sensitive config.

This externalizing of config also works with the <connectionStrings> section, except you use the configSource attribute like this:

<connectionStrings configSource="secretConnectionStrings.config">
</connectionStrings>

Connection Strings/App Secrets in Azure

When you're deploying a web app to Azure (as often these apps are deployed from source/GitHub, etc) you should NEVER put your connection strings or appSettings in web.config or hard code them.

Instead, always use the Application Settings configuration section of Web Apps in Azure.

These collection strings and name value pairs will automatically be made available transparently to your website so you don't need to change any ASP.NET code. Considered them to have more narrow scope than what's in web.config, and the system will merge the set automatically.

Additionally they are made available as Environment Variables, so you can Environment.GetEnvironmentVariable("APPSETTING_yourkey") as well. This works in any web framework, not just ASP.NET, so in PHP you just getenv('APPSETTING_yourkey") as you like.

The full list of database connection string types and the prepended string used for environment variables is below:

• If you select “Sql Databases”, the prepended string is “SQLAZURECONNSTR_”
• If you select “SQL Server” the prepended string is “SQLCONNSTR_”
• If you select “MySQL” the prepended string is “MYSQLCONNSTR_”
• If you select “Custom” the prepended string is “CUSTOMCONNSTR_”

ASP.NET 5

ASP.NET 5 has the concept of User Secrets or User-Level Secrets where the key/value pair does exist in a file BUT that file isn't in your project folder, it's stored in your OS user profile folder. That way there's no chance it'll get checked into source control. There's a secret manager (it's all beta so expect it to change) where you can set name/value pairs.

ASP.NET also has very flexible scoping rules in code. You can have an appSettings, then an environment-specific (dev, test, staging, prod) appSettings, then User Secrets, and then environment variables. All of this is done via code configuration and is, as I mentioned, deeply flexible. If you don't like it, you can change it.

var builder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json")
    .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

if (env.IsDevelopment())
{
    // For more details on using the user secret store see http://go.microsoft.com/fwlink/?LinkID=532709
    builder.AddUserSecrets();
}

builder.AddEnvironmentVariables();
Configuration = builder.Build();

So, in conclusion:

• Don't put private stuff in code.
• Seems obvious, but...
• Avoid putting private stuff in common config files
  • Externalize them AND ignore the externalized file so they don't get checked in
• Consider using Environment Variables or User-level config options.
  • Keep sensitive config out of your project folder at development time

I'm sure I missed something. What are YOUR tips, Dear Reader?

Resources

• Best practices for deploying passwords and other sensitive data to ASP.NET and Azure App Service

Image Copyright Shea Parikh - used under license from http://getcolorstock.com

Sponsor: Big thanks to Infragistics for sponsoring the blog this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

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.

About   Newsletter

Hosting By

I've never much liked the whole "dnvm" and "dnu" and "dnx" command line stuff in the new ASP.NET 5 beta bits. There's reasons for each to exist and they were and they have been important steps, both organizationally and as aids to the learning process.

My thinking has always been that when a new person sits down to learn node, python, ruby, golang, whatever, for the most part their experience is something like this. It should be just as easy - or easier - to use .NET.

This is just a psuedocode. Don't sweat it too much.

apt-get install mylang #where mylang is some language/runtime
#write or generate a foo.fb hello world program
mylang foo #compiles and runs foo

I think folks using and learning .NET should have the same experience as with Go or Ruby.

• Easy To Get - Getting .NET should be super easy on every platform.
  • We are starting to do this with http://get.asp.net and we'll have the same for .NET Core alone, I'm sure.
• Easy Hello World - It should be easy to create a basic app and build from there.
  • You can "dotnet new" and get hello world. Perhaps more someday?
• Easy Compile and Run
  • Just "dotnet run" and it compiles AND executes
• Real .NET
  • Fast, scalable, native speed when possible, reliable

I've been exploring the (very early but promising) work at https://github.com/dotnet/cli that will ship next year sometime.

IMPORTANT NOTE: This toolchain is [today] independent from the DNX-based .NET Core + ASP.NET 5 RC bits. If you are looking for .NET Core + ASP.NET 5 RC bits, you can find instructions on the http://get.asp.net/.

Once I installed the "dotnet" cli, I can do this:

>dotnet new
>dotnet restore
>dotnet run

Imagine with me, when you combine this with the free Visual Studio Code editor which runs on Mac, Windows, and Linux, you've got a pretty interesting story. Open Source .NET that runs everywhere, easily.

Here is a longer command line prompt that includes me just typing "dotnet" at the top to get a sense of what's available.

C:\Users\Scott\Desktop\fabulous>dotnet
.NET Command Line Interface
Usage: dotnet [common-options] [command] [arguments]

Arguments:
  [command]     The command to execute
  [arguments]   Arguments to pass to the command

Common Options (passed before the command):
  -v|--verbose  Enable verbose output

Common Commands:
  new           Initialize a basic .NET project
  restore       Restore dependencies specified in the .NET project
  compile       Compiles a .NET project
  publish       Publishes a .NET project for deployment (including the runtime)
  run           Compiles and immediately executes a .NET project
  repl          Launch an interactive session (read, eval, print, loop)
  pack          Creates a NuGet package

C:\Users\Scott\Desktop\fabulous>dotnet new
Created new project in C:\Users\Scott\Desktop\fabulous.

C:\Users\Scott\Desktop\fabulous>dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16231

  CACHE https://www.myget.org/F/dotnet-core/api/v3/index.json
  CACHE https://api.nuget.org/v3/index.json
Restoring packages for C:\Users\Scott\Desktop\fabulous\project.json
Writing lock file C:\Users\Scott\Desktop\fabulous\project.lock.json
Restore complete, 947ms elapsed

NuGet Config files used:
    C:\Users\Scott\AppData\Roaming\NuGet\nuget.config
    C:\Users\Scott\Desktop\nuget.config
    C:\Users\Scott\Desktop\fabulous\nuget.config

Feeds used:
    https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/
    https://api.nuget.org/v3-flatcontainer/

C:\Users\Scott\Desktop\fabulous>dotnet run
Hello World!

Note that I ran dotnet restore once before on another projects so that output was not very noisy this time.

Native Compilation of .NET applications

This is cool, but things get REALLY compelling when we consider native compilation. That literally means our EXE becomes a native executable on a platform that doesn't require any external dependencies. No .NET. It just runs and it runs fast.

It's early days, and right now per the repro it's just hello world and a few samples but essentially when you do "dotnet compile" you get this, right, but it requires the .NET Core Runtime and all the supporting libraries. It JITs when it runs like the .NET you know and love.

But if you "dotnet compile --native" you run it through the .NET Native chain and a larger EXE pops out. But that EXE is singular and native and just runs.

Again, early days, but hugely exciting. Here's the high-level engineering plan on GitHub that you can explore.

Related Projects

There are many .NET related projects on GitHub.

• The .NET home repo links to 100s of .NET projects, from Microsoft and the community.
• The .NET Core repo links to .NET Core related projects from Microsoft.
• The ASP.NET home repo is the best place to start learning about ASP.NET 5.
• http://dotnet.github.io is a good place to discover .NET Foundation projects.

Sponsor: Big thanks to Redgate for sponsoring the feed this week! Have you got SQL fingers? Try SQL Prompt and you’ll be able to write, refactor, and reformat SQL effortlessly in SSMS and Visual Studio. Find out more with a 28 day free trial!

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.

About   Newsletter

Hosting By

When you first start learning about 3D Printing you'll usually find yourself looking at a bunch of brightly colored plastic busts. The first 3D printed thing I ever saw was a florescent green Yoda head. First you're like "HOW DID YOU DO THIS?" but quickly you're more like "OK, how many brightly colored plastic pieces of crap do I really need in my life?"

At this point you've likely dismissed 3D Printing as the world of the rich, the insane, or the nerdy, or all three. This is where I was.

I thought a 3D Printer was a $2000 thing, and of course, that's a heck of a lot of money. But I wanted to get into 3D Printing because I'd started to talk to some more advanced folks locally here in Portland and they assured me that it was cheaper than I thought and more useful than I thought. I got a $599 Printrbot Simple Metal from Amazon. You can also get a kit and assemble it yourself for $539 but the assembling is kind of hard work.

Later as I was having so much fun I got a Dremel 3D Printer for $899 also off Amazon and it's been absolutely reliable and super fun. I now consider the Printrbot a great "prosumer" hobbyist printer for folks to tinker with and improve, but the Dremel just prints, and it prints well. I had it printing well within 10 minutes of unboxing it. Both of these printers are great, but the Dremel (in my experience) has required less adjustment.

I've learned three things. They are perhaps obvious to you, but they have been amazing for me and my sons as we learn more about 3D Printing.

Lesson 1 - You can upgrade your 3D Printer

There's a great website called Thingiverse that is filled with models that others have made or remixed. You can join in and just download, or, ideally, create your own models and share. I've used Tinkercad with the kids to create new models.

One of the great jokes in 3D Printing is that people with printers never print anything useful, they just print upgrades to their printers. When you are getting started, this is actually kind of true. I took my PrinterBot and printed a base, a spool holder (figuring out where to safely and reliably hang the spools of plastic filament is a big problem.

The Dremel has a top lid and usually you'll have the filament inside on a special plastic spool holder. However, if you use larger or non-Dremel filaments you'll want a reliable "big spool" solution. There's a "system" at Thingiverse called the "OmniStand" that you can print that will literally replace the internal one. You can also print an OmniStand for the top of the printer (as seen in this picture below) that will let it print off very large spools.

These were small but significant victories. This was a reminder to my sons and I that we could change these devices and make them work how WE wanted, not necessarily how the they were designed.

NOTE: You can also upgrade the Nozzle in your printer. Later I'll talk about "exotic" filaments that can give amazing results but are also more abrasive and can wear out the stock nozzles that come with your printer. I upgraded the nozzle on my Dremel for just $14.99 using this Brass Nozzle from Proto-Pasta and was able to make the swap and get back to printing in about 20 minutes, not counting the feeling of accomplishment.

OK, so you can print things to make your printer work better, cool...what else?

Lesson 2 - There are "exotic" plastic filaments that are game changers

There's a local small business just over the river in Vancouver, Washington called "Proto-Pasta." They a company of just three people that started as a Kickstarter two years ago. They sell "exotic" plastic filaments that have additives and properties that take your prints out of the "bright plastic crap" category and into something more interesting.

They have a filament with added Carbon Fiber that has created some of the smoothest and most amazing prints I've ever made. It doesn't gain strength with this addition, but rather rigidity. They have a Stainless Steel filament that is great for making jewelry or robots or anything that you want to have the heft and feel of steel. They've even got a filament with Iron so your prints can react to magnets.

I've used their High-Temperature filament that starts out clear but you bake it (literally, in your oven) afterwards and it'll shrink slightly and get VERY hard and turn opaque.

More recently I've been trying a filament with added Pine (yes, wood) that not only smells great but looks amazing with wood flecks inside the filament.

I've made dishes, vases, pieces of art for shelves, and geometric shapes for gifts this Christmas. Each one is VERTY different just by changing the filament. It's been more than changing color. These exotics change the texture and weight, and by making small changes in the software you can make them thicker or, in my case, thinner and more translucent.

I hope the folks who get these for Christmas appreciate the work and thought that went into them.

Lesson 3 - You can print parts and then assemble things using bolts, glue, etc.

This one may be obvious, but you don't have to do everything with plastic. My 8 year old and I are slowly making a "T4 Quadcopter" designed by Brendan from New Zealand (a reader of this blog) and this project will require not only lots of printed pieces but assembled pieces. You can super glue, screw, bolt, zip-tie and snap 3D printed parts together. I've been surprised at how string these parts can be when they are combined. This quadcopter will be held together with small metric nuts and bolts and zip-ties as well as some very clever snaps built-in as part of the 3D Printed model.

We are having a blast with this family hobby. We've fixed things around the house, made art, explored material science, thought about geometry, and learned about how software and hardware work together to create something bigger. Are you getting into 3D Printing?

Related Links

• 3D Printer Shootout - $600 Printrbot vs. $20,000 uPrint SE Plus
• Moving beyond Beginner when 3D Printing and becoming a Handy Person
• Review: Dremel 3D Printer and initial impressions of the HP Sprout
• The Basics of 3D Printing in 2015 - from someone with 16 WHOLE HOURS' experience

Also, please do follow my adventures on Instagram at @shanselman!

Sponsor: Big thanks to Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

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.

About   Newsletter

Hosting By