Writing JSON has became trivial in C# and there’s no class I like better for that purpose than Utf8JsonWriter. Just look at a simple example:
var jsonUtf8 =newUtf8JsonWriter(Console.OpenStandardOutput(),newJsonWriterOptions(){ Indented =true});
jsonUtf8.WriteStartObject();
jsonUtf8.WriteString("Test","2+2");
jsonUtf8.WriteEndObject();
jsonUtf8.Flush();
This simple code will produce perfectly valid JSON:
{"Test":"2\u002B2"}
While valid, you’ll notice this is slightly different than any other programming language would do. A single plus character became escape sequence \u002B.
In their eternal wisdom, .NET architects decided that, by default, JSON should be over-escaped and they “explained” their reasoning in the ticket. Essentially they did it out of abundance of caution to avoid any issues if someone puts JSON where it might not be expected.
Mind you, in 99% of cases JSON is used in HTTP body and thus doesn’t need this but I guess one odd case justifies this non-standard but valid output in their minds. And no, other JSON encoders don’t behave this way either. Only .NET as far as I can tell.
Fortunately, some time later, they also implemented what I (alongside probably 90% of developers) consider the proper JSON encoder which escapes just mandatory characters and leaves the rest of text alone. It just requires a small extra parameter.
Using UnsafeRelaxedJsonEscaping is not unsafe despite it’s name; darn it, it’s not even relaxed as compared to the specification. It’s just a properly implemented JSON encoder without any extra nonsense thrown in.
One of most exciting recent developments in laptop world for me is definitely the framework laptop. A major component of that concept are its expansion cards. And, of course, you can build your own.
This repository is quite encompassing if you’re using KiCAD. However, for those who love nicer tools (ehm, DipTrace), it’s annoying to find that there is no board size specification in human readable format (and no, KiCAD XML is not). So I decided to figure it out.
To cut the long story short, here are the board outline points for the expansion card PCB:
(0.0, 0.0)
(26.0, 0.0)
(26.0, 26.5)
(25.0, 26.5)
(25.0, 30.0)
(17.7, 30.0)
(17.7, 28.0)
(16.0, 28.0)
(16.0, 29.0)
(10.0, 29.0)
(10.0, 28.0)
(8.3, 28.0)
(8.3, 30.0)
(1.0, 30.0)
(1.0, 26.5)
(0.0, 26.5)
In order to make it slightly nicer to handle, each corner is additionally rounded with a 0.3 mm radius.
And let’s not forget two holes at (1.7, 10.5) and (24.3, 10.5), both with a 2.2 mm diameter and 4.9 mm keepout region.
With that information in hand, one can create PCB board in any program they might prefer. Of course, I already did so for DipTrace and you download the files here.
And yes, PCB is just a first step in a development process. What I found the hardest is actually getting appropriate connectors for the enclosure as there’s not too much height to work with.
PS: No, I do not own framework laptop at this time. I am waiting for 15.6" model as 13.5" is simply too small for me when not used external monitor.
If one desires to run HTTPs server from C#, they might get the following warning:
Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date. To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'. For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
And yes, once could follow instructions and have everything running. But where’s the fun in that?
Alternative approach would be to load certificate from the file and .NET makes that really easy.
privatestaticX509Certificate2?GetCertificate(){var certFilename = Path.Combine(AppContext.BaseDirectory,"my.pfx");if(File.Exists(certFilename)){try{returnnewX509Certificate2(certFilename);}catch(CryptographicException ex){// log error or whatever}}returnnull;}
So, when bringing server up we can just call it using something like this:
While creating build system that works across the platforms, one can find issues in the most basic things. And that’s even when shell is the same. For example, while Bash on Linux and Windows works out the same, a lot of supporting tools differ - a lot. And there’s no better example than creating a zip archive.
Under Linux you can count on zip command being available. Even if one doesn’t have it, it’s easy to install without messing with their desktop. On Windows story gets more complicated. Git Bash for example doesn’t have it even compiled and there’s no really good way to add it. Yes, you can use any application but different one is installed on every system. To create more “fun”, supporting multiple applications also means dealing with their command-line arguments. And yes, 7-Zip has completely different syntax as compared to WinRAR.
However, when it comes to making zip archive, there’s actually a solution that works for both Windows (via Git Bash) and Linux. Surprisingly, the answer is perl.
If one is careful to use Perl’s older IO::Compress::Zip library, creating an archive becomes a simple task:
perl -e'
use strict;
use warnings;
use autodie;
use IO::Compress::Zip qw(:all);
zip [
"src/mimetype",
<"src/META-INF/*.*">,
<"src/OEBPS/*.*">,
<"src/OEBPS/chapters/*.*">
] => "bin/book.epub",
FilterName => sub { s[^src/][] },
Zip64 => 0,
or die "Zip failed: $ZipError\n";
'
Yeah, might not be ideal when it comes to beauty but it definitely works across platforms.
Since PowerShell comes installed with every Windows, I find it ideal tool for initial system setup when nothing else is installed. And one of the tasks I need it for is setting up auto-start.
My standard approach for setting application auto-start used to be to just use regedit.exe and load prepared registry file. But, as I was rewriting my setup scripts, I figured it’s time to update this too.