After a long time of unreliable results with Web Compiler, especially in TFS, I decided to replace it with node-sass. Web Compiler is an extension to Visual Studio that listens to changes in your .scss files (among others) and compiles them. It can also be configured to run as part of your TFS build. With our solution this has however been highly unreliable, where Web Compiler claims that files have been compiled, but the changes you made are not reflected in the resulting bundles.
A week before my annual subscription of CrashPlan would expire I got an e-mail informing me that the CrashPlan for Home service was discontinued. My subscription was extended by 60 days to give me enough time to find another service. I’ve used it for a couple of years and have been quite happy with it, except maybe for the micro stuttering I experienced. It had the possibility to back up to a local external drive as well as online (offsite) with plenty of configurable options.
I have recently migrated my blog from WordPress to Hugo. That is, switching from a database-based web content management system with loads of themes, plugins and a large user base to a statically generated site with no server-side logic and a small feature set where I must build most things myself. The switch was by no means necessary, I had cheap hosting at a web hotel I will still use for other sites after the migration, speed was good with WP Super Cache and so on.
As I have worked more and more with CSS during the last year, both at work and with an updated version of this blog, I have come to the following conclusions regarding the Sass vs SCSS syntax. SCSS is the obvious default choice as it’s a more natural extension of CSS and that you can simply rename an existing .css file. In a team with several developers focused more on server-side, it’s usually easier to explain SCSS than Sass syntax.