What a great title. "URLs are UI." Pithy, clear, crisp. Very true. I've been saying it for years. Someone on Twitter said "this is the professional quote of 2017" because they agreed with it.
So many folks spend time on their CSS and their UX/UI but still come up with URLs that are at best, comically long, and at worst, user hostile.
Search Results that aren't GETs - Make it easy to share
Even non-technical parent or partner things URLs are UI? How do I know? How many times has a relative emailed you something like this:
"Check out this house we found! https://www.somerealestatesite.com/ homes/for_sale/ search_results.asp"
That's not meant to tease non-technical relative! It's not their fault! The URL is the UI for them. It's totally reasonable for them to copy-paste from the box that represents where they are and give it to you so you can go there too!
Make it a priority that your website supports shareable URLs.
URLs that are easy to shorten - Can you easily shorten a URL?
SIDE NOTE: Yes, I am fully aware of my own hypocrisy with this issue. My blog software was written by a bunch of us in 2002 and our URLs are close to OK, but their age is showing. I need to find a balance between "Cool URLs don't change" and "should I change totally uncool URLs." Ideally I'd change my blog's URLs to be all lowercase, use hyphens for spaces instead of CamelCase, and I'd hide the technology. No need (other than 17 year old historical technical ones) to have .aspx or .php at the end of your URL. It's on my list.
What is your advice, Dear Reader for good URLs?
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
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.
Buy one via my Amazon referral links so I can keep blogging in my spare time AND buy tacos. Your use of these links gives me walking around money. Thanks for reading!
I've been very happy with the TP-Link AC3200 Router I got two years ago. It's been an excellent and solid router. However, as the kids get older and the number of mobile devices (and smart(ish) devices) in the house increase, the dead wifi spots have become more and more noticeable. Additionally I've found myself wanting more control over the kids' internet access.
There's a number of great WiFi Survey Apps but I was impressed with the simplicity of this Windows 10 WiFi Survey app, so I used it to measure the signals around my house, superimposed with a picture of the floor plan.
Here's the signal stretch of the TP-Link. Note that when you're using a WiFi Survey app you need to take into consideration if you're measuring 2.4GHz that gives you better distance at slower speeds, or 5GHz that can give you a much faster connection at the cost of range. As a general rule in a single room or small house, 5GHz is better and you'll absolutely notice it with video streaming like Netflix.
Below is a map of the 5GHz single for my single TP-Link router. It's "fine" but it's not epic if you move around. You can guess from the map that the router is under the stairs in the middle.
You can also guess where concrete walls are, as well as the angles of certain vectors that pass through thick walls diagonally and affect the signal. Again, it's OK but it's starting to be annoying and I wanted to see if I could fix it.
SIDE BAR: It is certainly possible to take two routers and combine them into one network with a shared SSID. If you know how to do this kind of thing (and enjoy it) then more power to you. I tried it out in 2010 and it worked OK, but I want my network to "just work" 100% of the time, out of the box. I like the easy setup of a consumer device with minimal moving parts. Mesh Networking products are reaching the consumer at a solid price point with solid tech so I thought it was time to make the switch.
Below is the same map with the same locations, except using the AmpliFi HD (High-Density) Home Wi-Fi System from Ubiquiti Networks. This is the consumer (or "prosumer") version of the technology that Ubiquiti (UBNT) uses in their commercial products.
AmpliFi HD includes the router and two "mesh points." These are extenders that use a mesh tech called 3x3 MIMO. They can transmit and receive via 3 streams at a low level. MIMO is part of the 802.11n spec.
Note that this improvement is JUST using the AmpliFi main router. When you do a Wifi Survey the "Mesh Points" will show up as the same SSID (the same wireless network) but they'll have different MAC Address. That means in my list of networks in the Survey tool my "HanselMesh" network appears three times. Don't worry, it's one SSID and your computers will only see ONE network - it's just advanced tools that see each point. It's that "meshing" of n number of access points that is the whole point.
These two maps below are the relative strengths of just the mesh points. It's the union of all three of these maps that gives the clear picture. For example, one mesh point covers the living area fantastically (as does the router itself) while the other covers the garage (not that it needs it) and the entire office.
Between the main router and the two included mesh points there are NO dead spots in the house. I'll find the kids in odd corners with an iPad, behind a couch in the play room where they couldn't get signal before. I'm finding myself sitting in different rooms than I did before just because I can roam without thinking about it.
I would suspect I could get away with buying just the AmpliFi Router (around US$133) and maybe one mesh point extender but the price for all three (router + 2 mesh points) is decent. The slick part is that you can add mesh points OR a second router. It's the second router idea that is most compelling for multi-floor buildings that also have a wired network. For example, I could add a second router (not a mesh point) upstairs and plug it into the wall (so it's "wire backed").
The mesh points plug into the wall and just sit there. You can adjust them, bend them to point towards the router, and best of all - move them at will. For example, when I set up the network initially I put the two mesh points where I thought they'd work best. But one didn't and Netflix was dropping. I literally unplugged it and moved it into the hallway and plugged it in. A minute later that whole area was full speed. This means if I did/do find a dead spot, I could just move the mesh point either temporarily or permanently.
The router is adorable. Like "I wish it wasn't in a closet" adorable. It's pretty enough that you'll want it on your desk. It has a great LCD touchscreen and a lighted base. The touchscreen shows your IP, total bandwidth this month (very useful, in fact), and bandwidth currently used.
The router is best set-up with an iPhone/iPad or Android device. There is a VERY minimal web interface but you really can't manage the Amplfi (as of the time of this writing) with a web browser - it really is designed to be administered with a mobile app. And frankly, I'm OK with it because the app is excellent.
The download/upload numbers there aren't the maximum speed - it's the bandwidth being used right now. You can test the speed elsewhere in the app. I have 35Mb/s up and down (usually) in my house, but Gigabit inside (which is useful as I have a Synology server internally).
There a lot of ways to restrict internet for the kids. I like that the Amplify lets me group devices and apply time-limits to them. Here the Xbox and two tablets can't use the internet until 9am and they turn off at bedtime.
Notice the pause buttons as well. I can temporarily pause internet on any one device (or group of devices) whenever.
When you're setting up the network and positioning the mesh points you can see near-realtime signals updates in the app.
And once it's all done, you can impose a basic QoS (Quality of Service) on individual devices by telling the AmpliFi what they are used for. Here I've setup a device for multi-player gaming, while some iPads are used mostly for streaming.
Setup is a snap. It took longer to go to each device and connect them to the new network than it did to set up the network. I suppose I could have kept the same SSID and password as the old network but I wanted a fresh start and easier A/B testing.
So far I have been 100% thrilled with the AmpliFi HD. It's important to point out again that AmpliFi is the consumer arm of Ubiquiti (UBNT) and that a dozen programmer/techie-types on Twitter insisted suggested that I needed these Enterprise/Commercial Access Points. I get it. They are more advanced, fancier, offer more stats and more control. But honestly, my house isn't that big, the data I'm pushing around isn't that complex, and I don't want a Commercial Level of control. I was (and am) thoroughly impressed with the consumer stuff. The app is excellent and improving. The coverage is complete and fast. The AmpliFi is rated at 450 Mbps for 2.4 GHz and 1.3 Gbps for 5 GHz). Even if I upgrade my internet to my localities max of 150 Mbps (I only pay for 35 Mbps today) I'm not anywhere near that limit externally, and I'm not doing anything close internally.
That said, here's some things I'd like in future updates:
Simpler port-forwarding with common rules. "This xbox/that service"
An open source VPN server. I'd like to VPN directly into the Ubiquiti, rather than into my Synology.
More quality of service/prioritization details. "The office server always has preferred packets, period"
Mobile alerts - I'd like to know if I go over x bandwidth, or if we are streaming at x Mbs for y hours.
A fully featured administration web console.
And yes, I realize NOW I should have called the Network "Hanselmesh." Missed opportunity.
I highly recommend the AmpliFi HD. I frankly have no complaints other than my small wish list above. Buy one via my Amazon referral links so I can keep blogging in my spare time AND buy tacos. Your use of these links gives me walking around money. Thanks for reading!
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
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.
I've had a number of great guests on the podcast lately. One topic that has come up a number of times is the "toy project." I've usually kept mine private - never putting them on GitHub - Somewhat concerned that people would judge me and my code. However, hypocrite that am (aren't we all?) I have advocated that others put their "Garage Sale Code" online. So here's some crappy code. ;)
The Preamble
While I've been working as an engineer for 25 years this year, I didn't graduate from school with a 4 year degree until 2003 - I just needed to get it done, for myself. I was poking around recently and found my project from OIT's CST352 "Operating Systems" class. One of the projects was to create a "Virtual CPU and OS." This is kind of a thought exercise. It's not really a parser/lexer - although there is both - and it's not a real OS. But it needs to be able to take in a made-up quasi-Assembly Language instruction set and execute them on a virtual CPU while managing virtual memory of arbitrary size. Again, a thought exercise made real to confirm that the student understands the responsibilities of a CPU.
Here's an example "application." Confused yet? Here's the original spec I was given in 2002 that includes the 36 instructions the "CPU" should understand. It has 10 general-purpose 32bit registers address as 1 through 10. Register 10 is the stack pointer. There are two bit flag registers - sign flag and zero flag.
Instructions are "opcode arg1 arg2" with constants prefixed with "$."
I write my homework assignment in 2002 in the idiomatic C# of the time on .NET 1.1. That means no Generics<T> - I had to make my own strongly typed collections. That means C# has dozens of (if not a hundred) language and syntax improvements. I didn't use a Unit Testing Framework as TDD was just starting around 1999 during the XP (eXtreme Programming) days and NUnit was just getting start. It also uses "unsafe" to pin down memory in a few places. I'm sure there are WAY WAY WAY better and more sophisticated ways to do this today in idiomatic C# of 2017. Those are excuses, the real reasons are my own ignorance, ability, combined with some night-school laziness.
One of the more fun parts of this exercise was moving from physical memory (a byte array as I recall) to a full-on Memory Manager where each Process thought it could address a whole bunch of Virtual Memory while actual Physical Memory was arbitrarily sized. Then - as a joke - I would swap out memory pages as XML! ;) Yes, to be clear, it was a joke and I still love it.
You can run an "app" by passing in the total physical memory along with the text file containing the program, but you can also run an arbitrary number of programs by passing in an arbitrary number of text files! The "TinyOS" will handle each process thinking it has its own memory and will time
If you are more of a visual learner, perhaps you'd prefer this 20-slide PowerPoint on this Tiny CPU that I presented in Malaysia later that year. You dig those early 2000-era slides? I KNOW YOU DO.
Updating a .NET 1.1 app to cross-platform .NET Core 2.0
I decided to use Visual Studio 2017 to upgrade it, and even worse I decided to use .NET Core 2.0 which is currently in Preview. I wanted to use .NET Core 2.0 not just because it's cross-platform but also because it promises to have a pretty large API surface area and I want this to "just work." The part about getting my old application running on Linux is going to be awesome, though.
Visual Studio then pops a scary dialog about upgrading files. NOTE that another totally valid way to do this (that I will end up doing later in this blog post) is to just make a new project and move the source files into it. Natch.
Visual Studio says it's targeting .NET 2.0 Full Framework, but I ratchet it up to 4.6 to see what happens. It builds but with a bunch of errors about Obsolete methods, the most interesting one being this one:
Warning CS0618 'ConfigurationSettings.AppSettings' is obsolete: 'This method is obsolete, it has been replaced by System.Configuration!System.Configuration.ConfigurationManager.AppSettings' C:\Users\scott\Downloads\TinyOSOLDOLD\OS Project\CPU.cs 72
That's telling me that my .NET 1/2 API will work but has been replaced in .NET 4.x, but I'm more interested in .NET Core 2.0. I could make my EXE a LIB and target .NET Standard 2.0 or I could make a .NET Core 2.0 app and perhaps get a few more APIs. I didn't do a formal analysis with the .NET Portability Analyzer but I will add that to the list of Things To Do. I may be able to make a library that works on an iPhone - a product that didn't exist when I started this assignment. That would be Just Cool(tm).
I decided to just make a new empty .NET Core 2.0 app and copy the source .cs files into it. A few interesting things.
My app also used "unsafe" code (it pins memory down and accesses it directly).
It has extensive inline documentation in comments that I used to use NDoc to make a CHM Help file. I'd like that doc to turn into HTML at some point.
It also has an appsettings.json file that needs to get copied to the output folder when it compiles.
While I could publish it to a self-contained .NET Core exe, for now I'm running it like this in my test batch files - example:
Other than the obsolete configuration warning and a few malformed XML comments, the app compiled and ran! You can actually "watch" the nightmare process here https://github.com/shanselman/TinyOS/commits/Core2Port in the form of GitHub commits. I also moved the docs from a 2002 Word Doc to Markdown so be sure to explore the fairly extensive spec https://github.com/shanselman/TinyOS.
The only significant change was loading the config. Configuration is even more different on .NET Core 2.0 than Full Framework. It's FAR more, ahem, configurable. I could have used "Options," I could have written my own config provider if it was important to keep the file format.
This little TinyOS has a bunch of config options that come in from a .exe.config file in XML like this (truncated):
<configuration> <appSettings> <!-- Must be a factor of 4 This is the total Physical Memory in bytes that the CPU can address. This should not be confused with the amount of total or addressable memory that is passed in on the command line. --> <add key="PhysicalMemory" value="128" /> <!-- Must be a factor of 4 This is the ammount of memory in bytes each process is allocated Therefore, if this is 256 and you want to load 4 processes into the OS, you'll need to pass a number > 1024 as the total ammount of addressable memory on the command line. --> <add key="ProcessMemory" value="384" /> <add key="DumpPhysicalMemory" value="true" /> <add key="DumpInstruction" value="true" /> <add key="DumpRegisters" value="true" /> <add key="DumpProgram" value="true" /> <add key="DumpContextSwitch" value="true" /> <add key="PauseOnExit" value="false" />
I have a few choices. I could make a Configuration Provider and reach .NET Core to read this format (there's an XML adapter, in fact) or make the code porting easier by moving these "name/value" pairs to a JSON file like this:
This was just a few minutes of search and replace to change the XML to JSON. I could have also written a little app or shell script. By changing the config (rather than writing an adapter) I could then keep the code 99% the same.
My code was doing things like this (all over...there was no DI container yet):
And I'd like to avoid major refactoring - yet. I added this bit of .NET Core configuration at the top of the EntryPoint and saved away an IConfigurationHost:
var builder = new ConfigurationBuilder() .AddJsonFile("appsettings.json"); Configuration = builder.Build();
I've got a Dictionary in the format of the IConfiguration host called "Configuration." So now I just do this in a dozen places and the app compiles again:
This brings up that feeling we all have when we look at old code - especially our own old code. I should have abstracted that away! Why didn't I use an interface? Why so many statics? What was I thinking?
We can beat ourselves up or we can feel good about ourselves and remember this. The app worked. It still works. There is value in it. I learned a lot. I'm a better programmer now. I don't know how far I'll take this old code but I had a lovely afternoon porting it to .NET Core 2.0 and I may refactor the heck out if it or I may not.
For now I did update the smoke tests to run on both Windows and Linux and I'm happy with the experiment.
Andy Clarke from New Zealand took the original spec and did the homework assignment in 2012! His project - 5 years ago, and 10 years after mine - includes some interesting changes. Rather than an EXE that takes in the programs from the command line, he's written over 221 NUnit 2 tests that check each individual component he's written as well as more comprehensive integration tests (as unit test) for the programs. The "Assembly" language has been changed from opcodes to more human readable commands like "move" and "add." I think Andy's solution is much nicer than mine, but he wouldn't pass the class because the spec was pretty clear and my teacher was a stickler. ;) I LOVE that someone else did this on their own!
Have YOU done a project like this, either in school or on your own?
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
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.
The .NET Core team really prides themselves on performance. However, it's not immediately obvious (as with all systems) if you just do Hello World as a developer. Just today I was doing a Ruby on Rails app in Development Mode with mruby - but that's not what you'd go to production with.
Dotnet Run - Builds and Runs Source Code in Development
That's a great question. If you install .NET Core 2.0 Preview - this person is on a Mac, but you can use Linux or Windows as well - then do just this:
$ dotnet new console $ dotnet run
It'll be about 3-4 seconds. dotnet is the SDK and dotnet run will build and run your source code. Here's a short bit from the docs:
The dotnet run command provides a convenient option to run your application from the source code with one command. It's useful for fast iterative development from the command line. The command depends on the dotnet build command to build the code. Any requirements for the build, such as that the project must be restored first, apply to dotnet run as well.
While this is super convenient, it's not totally obvious that dotnet run isn't something you'd go to production with (especially Hello World Production, which is quite demanding! ;) ).
Dotnet Publish then Dotnet YOUR.DLL for Production
Instead, do a dotnet publish, note the compiled DLL created, then run "dotnet tst.dll."
For example:
C:\Users\scott\Desktop\tst> dotnet publish Microsoft (R) Build Engine version 15.3 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved.
C:\Users\scott\Desktop\tst> dotnet publish --self-contained -r win10-x64 Microsoft (R) Build Engine version 15.3 for .NET Core Copyright (C) Microsoft Corporation. All rights reserved.
Note in this case I have a "Self-Contained" app, so all of .NET Core is in that folder and below. Here I run tst.exe, not dotnet.exe because now I'm an end-user.
I hope this helps clear things up.
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test, build and debug ASP.NET, .NET Framework, .NET Core, or Unity applications. Learn more and get access to early builds!
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.
There's a ton of cool new .NET Core open source projects lately, and I've very much enjoyed exploring this rapidly growing space. Today at lunch I was checking out a project called "Brighter." It's actually been around in the .NET space for many years and is in the process of moving to .NET Core for greater portability and performance.
Brighter is a ".NET Command Dispatcher, with Command Processor features for QoS (like Timeout, Retry, and Circuit Breaker), and support for Task Queues"
Brighter also supports "Distributed Task Queues" which you can use to improve performance when you're using a query or integrating with microservices.
When building distributed systems, Hello World is NOT the use case. BUT, it is a valid example in that it strips aside any business logic and shows you the basic structure and concepts.
Let's say there's a command you want to send. The GreetingCommand. A command can be any write or "do this" type command.
internal class GreetingCommand : Command { public GreetingCommand(string name) :base(new Guid()) { Name = name; }
public string Name { get; private set; } }
Now let's say that something else will "handle" these commands. This is the DoIt() method. No where do we call Handle() ourselves. Similar to dependency injection, we won't be in the business of calling Handle() ourselves; the underlying framework will abstract that away.
We then register a factory that takes types and returns handlers. In a real system you'd use IoC (Inversion of Control) dependency injection for this mapping as well.
Our Main() has a registry that we pass into a larger pipeline where we can set policy for processing commands. This pattern may feel familiar with "Builders" and "Handlers."
private static void Main(string[] args) { var registry = new SubscriberRegistry(); registry.Register<GreetingCommand, GreetingCommandHandler>();
var builder = CommandProcessorBuilder.With() .Handlers(new HandlerConfiguration( subscriberRegistry: registry, handlerFactory: new SimpleHandlerFactory() )) .DefaultPolicy() .NoTaskQueues() .RequestContextFactory(new InMemoryRequestContextFactory());
var commandProcessor = builder.Build();
... }
Once we have a commandProcessor, we can Send commands to it easier and the work will get done. Again, how you ultimately make the commands is up to you.
Methods within RequestHandlers can also have other behaviors associated with them, as in the case of "[RequestLogging] on the Handle() method above. You can add other stuff like Validation, Retries, or Circuit Breakers. The idea is that Brighter offers a pipeline of handlers that can all operate on a Command. The Celery Project is a similar project except written in Python. The Brighter project has stated they have lofty goals, intending to one day handle fault tolerance like Netflix's Hystrix project.
One of the nicest aspects to Brighter is that it's prescriptive but not heavy-handed. They say:
Brighter is intended to be a library not a framework, so it is consciously lightweight and divided into packages that allow you to consume only those facilities that you need in your project.
Moving beyond Hello World, there are more fleshed out examples like a TaskList with a UI, back end Http API, a Mailer service, and core library.
Do be aware, again, that CQRS is not for every project. It's non-trivial and it's a "mental leap" as Martin Fowler puts it. If you buy in, you're adding complexity...for a reason. Keep your eyes open and do your research. It's a great pattern if you have a high performance/volume application that struggles with write concurrency or a flaky backend.
In fact there are quite a few mature CQRS libraries in the .NET open source space. I'll explore a few - which are your favorites?
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.
What a great title. "URLs are UI." Pithy, clear, crisp. Very true. I've been saying it for years. Someone on Twitter said "this is the professional quote of 2017" because they agreed with it. 
There's a ton of cool new .NET Core open source projects lately, and I've very much enjoyed exploring this rapidly growing space. Today at lunch I was checking out a project called "