Lavinski

https://www.daniellittle.dev/ I blog occasionally just to share or think. Regular topics include the web, fp and dotnet.

I wrote about why linking is useful recently https://www.daniellittle.dev/practical-hypermedia-controls. I've been using Hypermedia in my APIs for a few years now and it's been so useful for making great APIs. One of the things I really love about it is that you can test/use the API directly much more easily, because the knowledge about how to use it is in the API itself, instead of half hardcoded into the client.

The article goes through a series of examples to show motivations for the following:

1. Variables should not be allowed to change their type.

2. Objects containing the same values should be equal by default.

3. Comparing objects of different types is a compile-time error.

4. Objects must always be initialized to a valid state. Not doing so is a compile-time error.

5. Once created, objects and collections must be immutable.

6. No nulls allowed.

7. Missing data or errors must be made explicit in the function signature.

The idea being that each feature or constraint _enables_ you to reason and predict more about a program than you could otherwise.

I encourage anyone interested in these ideas to play around with F# or a similar language and get a feeling for how they influence your code. If you've mastered one paradigm such as OO one of the best ways to find holes in your mental models is to try and find another point of view to look at the same problems. Even if you keep writing most of your code like you do today, in the language you do today, it can still be beneficial.

Console or media center

This link (http://www.jongleberry.com/semver-has-failed-us.html) was also posted on HN a while ago.

HN: https://news.ycombinator.com/item?id=8154933

http://knockoutjs.com/ is also a great simple data binding lib but without any dependencies.

I hardly use an ORM anymore these days, however this article has a few issues.

First even when using SQL the author runs into the problem where splitting the database into two and having a reporting database would be much more efficient instead of having one database trying to meet all your needs. When you do writes you want transactions and 3rd normal form but when reporting 3rd normal form becomes a downside. This applies to attribute creep and data retrieval.

Second the dual schema problem is one that I think most ORM users know how to avoid. I generate the schema from the code directly, maybe with a little bit of fluent migrations to help move data.

The issue with transactions is a strange one. Ideally this is handled as a cross cutting concern in your application. This means it's consistent and transactions can be explicit and predictable. I'd do the same thing for any application.

The biggest issue here is I think the author has chosen the wrong tool. This application sounds like it would be well suited for event sourcing. I'm not going to go into it here but they solve these issues in an interesting way. Plus the data is event-based anyway.

On the front end Durandal.js Single Page App (similar to angular but MVVM). On the back end is a Rest web service written with ASP.NET Web.Api. Octopus Deploy for deployment.

It's also based on CQRS and DDD so data storage is aggregate based.

OpenGL is not actually open source. https://www.opengl.org/wiki/FAQ#Is_OpenGL_Open_Source.3F

One API for every device is great for developers targeting the Xbox and other windows devices.

There is actually a lot being done.

Reminds me of infinity (from https://inovaestudios.com/), which I've been watching for the past few years.

Just so you know there are a few guys out here (I'm one) that do like Microsoft and my Nokia Lumia is going great.