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.
Linq to SQL is a very nice abstraction when dealing with MSSQL, specifically the ability to conduct Linq queries in C# against MSSQL is pretty sweet. Updating a row through an ORM object, e.g. a HTTP Put, into the DB without doing manual field copying between the tracked entity and the de-serialized entity from the PUT is however a bit troublesome.
.Attach allows one to attach an entity to a Context, however calling SubmitChanges will not submit the changes of the attached object due to it not being marked as modified. Calling Attach(entity, asModified) with asModified = true did not work for me – an exception was thrown.
Apparently, this overload can only be called with asModified = true IFF Update Check is set to Never in the DBML file. This needs to be done for all properties of the given entity class, not sweet, but at-least it avoids the need to manually copy each member to an existing tracked Entity in the Context.
Accessing Atlassian Jira from a .NET application can be done very easily by installing the Atlassian Jira SDK.
From the nuget console.
This introduces the Jira assembly with alot of different classes and helper functions. E.g. one can connect to Jira using:
Jira.CreateRestClient(url, username, password)
which instantiates the Jira class which can be used to get Versions, Issues, etc. from Jira. A real treat using this library is that it proved Async methods, i.e. await keyword can be used throughout the usage.
getting all Versions of a specific project/key can be done using:
var results = await jiraConn.Versions.GetVersionsAsync(key)
getting issues using a specific JQL query can be done using:
var results = await jiraConn.Issues.GetIssuesFromJqlAsync(jql)
The System.AccessViolationException is thrown if one tries to marshal unamanaged memory from an invalid location, e.g. using a bad pointer. Prior to .NET 4.0, this exception was catch-able from within the CLR.
With .NET 4.0, System.AccessViolationException exception is no longer catched within the CLR, meaning that the application now crashes without necessarily logging the information in log4net. The stack trace can however be seen in windows’ event viewer.
It is possible to mark the method in which the exception is thrown using HandleProcessCorruptedStateExceptionsAttribute, thus making the method throw the exception into the CLR and making it catchable.