Quite recently I migrated this blog from WordPress to Hugo. Since I didn’t want to use a theme built by someone else, I had to add things like CSS and JavaScript myself. To be able to work with this locally in an efficient way and to be able to produce a complete build output in a reproducible manner, I had to automate the build steps. With WordPress I used Gulp for this, but I thought that might not be needed, so I made an attempt to do this using only npm scripts.
Read →
Lately I’ve been working on switching to Azure Media Services from another video platform on my customer’s web site. I’ve found some challenges related to sizing of the player in different browsers with different playback methods (HTML5, Flash and Silverlight). Particularly the size of the player when exiting full screen mode has been flaky. I can’t say for sure that this isn’t the fault of the web site it lives on, but I don’t see anything indicating that either.
Read →
If you have a Visual Studio project that uses Chutzpah for JavaScript tests, things recently got a lot easier with a long-awaited update.
Problem When all tests pass with the Chutzpah test runner everything is fine, but when you need to debug a test, things haven’t been as easy. Debugging the JS code in Visual Studio is something I never got working and never really cared about anyway. The best debugging tool for JavaScript is of course the web browser, but when selecting Open in browser in Visual Studio, Chutzpah has served the HTML test page (Jasmine in my case) through the FILE:/// protocol.
Read →
I have stored settings in applications built on SharePoint in a number of ways over the years, including SharePoint lists, the property bag and even web.config. As I have done most of the recent development using AngularJS and also had the need to store and fetch configuration values beyond simple data types, I have start using another way of storing these settings.
By storing text files with json configuration objects in a document library I get a couple of benefits.
Read →
As someone working mostly with SharePoint server-side code, unit tests are something that requires quite some investment in time to get rolling with – and consequently not being done. Javascript is a different thing though. Since a big part of most projects using SharePoint is (or should be) done with Javascript, we should be testing that code. (Of course this applies to any system with a web interface, but I assume most of you that don’t have SharePoint in your CV’s are already doing this).
Read →
