I recently started a new Electron Typescript project using version 1.14 of VSCode. Getting the task runner up and running using CTRL+B did not initially work, due to the fact that tasks.json is auto-generated as version 2.0.0 compared to version 0.1.0 which was the default in VSCode 1.13.
In addition, the new VSCode supports task auto-detection which confused the hell out of me due to it detecting tsconfig.json and asking me if I wanted to compile some typescript, even though my Tasks.json file was not yet created.
Apparently, MS added task-auto detection to the mainline during my vacation rendering tasks.json as an optionel part of a VSCode project. tasks.json is still required if one wish to create custom tasks or scan and parse the auto-detected tasks shell output.
This feature is great! since now I can make all my tasks in NPM without having to re-define them in tasks.json. VSCode can now detect these tasks automagically.
Although I still have to add the tasks in tasks.json if I want to define the default task addition to allowing VSCode to scan for problems.
I just returned from a well-earned 1 week vacation in a sommer cottage in south Denmark. For the trip, we packed the car with enough equipment for a month! Just look at that:
The car was 100% full. Two grown ups + a three year old and a three month old baby really require a lot of stuff.
My guess is we used about 25% of the items packed, hence we ‘overpacked’ for vacation – a typical mistake 🙂
My most recent productivity application, Shortcutty, requires the ability to hook into Windows to capture keydown events. The purpose is to show (or hide) the application whenever the user pressed CTRL+~.
I easily got this to work using the Win32 API + PInvoke in my .NET application. But, on some applications such as my Visual Studio instance, the hook failed by unknown reasons.
After a bit of debugging and digging through online archives on the matter, I quickly realized that the issue was as simple as my application not having administrator rights. The latter is required if I want my application to interact with other applications having higher privileges.
Visual Studio, as it happens, was running with admin-rights – thus my application was unable to hook into it, obviously for security reasons. Generally: a non-administrator process cannot interact with a process having administrator rights. You cannot even drag and drop between applications.
I needed a polygon library for my latest fun project (a TypeScript Build Engine). Google and NPM showed me the way to PolyK.JS, a very simple Polygon library that can do calculations on simple polygons, including Convex ones.
To my suprise, the library includes TypeScript definitions making the lib super easy to consume for my application. Supported operations include:
Gets the area of the polygon.
Triangulates the simple polygon
Slices the polygon.
Finds the closest point on the polygon given the intersection of a ray.
Finds the closest edge of the polygon.
Checks if a given point is within the polygon.
The library assumes that the polygon’s vertices are defined in an number array of X,Y coordinates. Super easy to use and highly recommended!
.NET Core is yet another .NET framework implementation implementing .NET Standard 1 (production) and .NET Standard 2 (beta) while also extending the standard with .NET core specific API’s such as Console and Thread (which are not part of the .NET Standard).
The cool thing with .NET Core is that it is: 100% open-source, 100% cross-platform and very modular. This stands in contrast to .NET and Mono since these are very monolithic implementations and huge in size. The source is available under MIT on GitHub: https://github.com/dotnet/core
Since .NET Core is very crossplatform, one can write .NET applications for x86/ARM Windows and x86/ARM Linux – and since it is very modular, the framework does not occupy much space compared to the desktop implementations.
API’s are generally not available in the framework but needs to be downloaded from NuGet, e.g. EntityFramework, ASP.NET, and even some Reflection support are an “add-on”.
I measured the raw framework installation on my Win 10 x64 box to about 70MB, while the .NET 4.6 framework is roughly 2000MB in size, that is, 28 times larger! Deployment wise, .NET Core SDK supports deploying application + framework meaning that the target does not have to have the specific framework installed.
The SDK will automatically pull all the dependencies into the publish package, which includes all NuGet dlls + native assemblies where applicable (e.g. if using sqlite .NET core wrapper). One can also publish to a specific target, such as Linux-x86 or Linux-arm, which will produce a platform specific package with an elf executable that can be executed.
Referencing .NET assemblies which does not target .NET Standard or .NET Core is not possible in .NET Core 1.1 since the APIs are incompatible. .NET Core 2.0 will include a compatibility layer making it possible to reference assemblies targeting other frameworks – although this sounds awesome, I have not experimented with this feature yet.
.NET Core is without a doubt the future of .NET!
Three.js is just this, an abstraction ontop of WebGL which takes care of the lower level stuff while exposing objects such as Geometry, Texture, Material, Camera etc. Getting a 3D scene up and running with correct perspective is super easy if one has a basic understanding of 3D. Typings are also available for three.js, meaning full Typescript support.
For fun, I implemented a Wolf3D engine using the original textures and sprites using THREE.JS. The entire renderer code is less than 220 lines, and this includes alot of copy pasting and commented out experimentation. My guess is that the code could be leaned to less than 150 lines. Source available at GitHub: https://github.com/horup/wolfts
The .NET framework has been branched into several implementations to match the constraints of the target platforms, e.g. Compact Framework for Pocket PC, Mono for Linux and the full .NET Framework for Windows.
This poses a problem regarding library compatibility between them. Writing a library is not straightforward since one has to target the specific framework in which the library is consumed. This has somewhat been alleviated by Portable Class Libraries (PCLs), since this type of library can target multiple frameworks. It is not a 100% solution, since when a new framework emerges the library in question is not automatically compatible with the new framework.
The solution has been to introduce a versioned formal API specification called .NET Standard. This standard is implemented by all the most common framework implementations. Writing a library targeting .NET Standard 1.0 ensures that the library can be consumed across different frameworks, if they implement the .NET Standard 1.0.
The .NET Framework 4.5 implements .NET standard 1.1 while .NET Framework 4.6 implements .NET Standard 1.4. Writing a library for both .NET Framework 4.5 and 4.6 can easily be done by targeting .NET Standard 1.1. Also, Windows Phone 8.1 and Mono implements .NET Standard 1.3 or above making the said library compatible with these implementations.
Each new version of the .NET Standard inherits from the previous version, making a new version a super-set of the old version. The API specification is written i C#, making it straight forward to read and adapt the API to a new implementation.
.NET Core is the latest framework implementing .NET Standard, more on this later.