With Visual Studio 2017, MSBuild and NuGet are better integrated, which removes the need for things like package.config, as packages can be tracked in the csproj directly, and custom MSBuild targets for packaging like NuProj, as one can now do it all from the csproj with the built in functionality in MSBuild 15.
All that is great, but I found myself stuck with an old SQLPROJ. I wanted to generate a NuGet package out of it. Here’s how one can do it:
Lots of ways to do this out there, ranging from “too much code” to “but, why?”. Here’s how I chose to do mine:
Somewhat recently I reduced the size of the virtual machine in which I host this blog. It is quite short on memory, but for the price I pay, can’t really complain.
Just now I was looking on memory usage on the machine, and noticed ps reporting over 100MB being help by npm:
andre@webserver ~]$ ps aux --sort -rss
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
ghost 247 0.0 23.2 1328872 117468 ? Sl Jun06 2:58 node index.js
ghost 199 0.0 7.5 1031804 37868 ? Ssl Jun06 0:00 npm
root 152 0.0 3.5 77340 17868 ? Ss Jun06 0:08 systemd-journald
As you can see, only about 38 MB is actually in RAM (RSS), the rest (VSZ) is either shared libs or in the swap. As you can see by the relative memory usage, I don’t have that much, so why not free those forty megabytes that are not really necessary?
In the process of trying to get Linux to boot on my Surface, I wanted to first get a kernel to boot on QEMU as to reduce as much of the work and investigation on the actual device.
Clearly that was a wise choice, as I obviously have no idea what I am doing. This post is to document it and hopefully save others time that might come here with the same questions I initially had.
On last post I got Windows Boot Manager to load GRUB (or what seems like it) on QEMU. Since then I was trying to cross-compile a newer version of GRUB for ARM and then load this newer version, instead of the original EFI partition I used when writing that post. That was harder than I first thought.
I didn’t get it to work. For now I’ll stick with that original GRUB imagine, knowing that the though of it will bug for a while - I got really curious to know how that image was made. I thought of recording whatever I found so far, in case I decide to continue investigating this in the future, or someone else is trying the same thing.
On my quest for Linux on Surface, I got too tiring of rebooting the tablet, tweaking some changes on the bcd store or efi partition, rebooting, failing and redoing the whole cycle again.
Surface has a ARM processor with a UEFI implemented. So I started looking whether I could emulate that setup to iterate more quickly over the changes I wanted to test, and only if they worked on the emulate system, I would go over the trouble of doing them on the actual tablet.
The other day I came across this interesting ebook by 0xAX, which got me interested into the whole x68 boot process.
On the same week, when cleaning up my office, I found my very old Surface tablet that runs Windows RT. My first thought was “can I boot something else in here? Maybe it will boot Linux?” and that was what I set to find out.
The prospect wasn’t promising. Surface ships with UEFI’s secure boot enabled, having the boot loader signed by Microsoft. In short, this means that any other code that runs after that needs to be trusted by the same party that signed the boot loader.
The other day I wanted to use Newtonsoft JSON serializer to convert objects to JSON strings, with the twist that if some property of the object was null it should be defaulted to a specific value in the JSON string.
There is the DefaultValueAttribute but that seems to work only for deserialization (or so it seemed when I gave up searching for an out of the box behavior).
It turns out you can implement a ContractResolver. Inheriting from the base DefaultContractResolver seems to be the easiest way to go. Then you can override just the CreateProperty method and provide an instance of IValueProvider to the property contract generated by that method. Check out the example below.
I’ve been working on this Visual Studio extension, called Commerce Runtime Handyman.
From time to time I spend a significant amount of time writing code on top of the Microsoft Dynamics Commerce Runtime framework, so I am hoping the time spent on this extension pays off, eventually ;)
The basic idea on this first release is that you don’t need to write up manually the request and response contract classes yourself, the tool can derive and create those out of a method definition.
Ghost’s out of the box import/export backup mechanism works well, but doesn’t backup images.
I wanted a simple command line I could call to backup my blog and move the backup file out of the server’s file system. Also, I didn’t want to stop Ghost’s node process to create the backup.
By default, Ghost uses sqlite as a database, which provides an easy way to perform online backups.
Below is a Gist of a small Bash script I put together to login to the blog’s server, perform the online backup of the database, gzip that together with the image folder and then copy over to the local machine.
