Some good reads on Angular 1.x

I decided it was time to learn one of the many JavaScript SPA frameworks, and figured that it would be a good idea to have a look at Angular.

Of course there have been many posts in the past detailing problems in Angular such as this one, this one and this one. There are also a number of articles discussing the good parts of the framework such as this one and this one. There is also the rewrite as Angular 2.0 going on which seems to progressing well with its emphasis on TypeScript and ES6.

I haven’t had time to write anything large in this framework, but have been impressed with the design of the framework and the clever ideas that it incorporates. For me, it was also a chance to get to grips with modern JavaScript development using npm and the associated tools.

The first book I read was AngularJS Up & Running: Enhanced productivity With Structured Web Apps by Shyam Seshadri & Brad Green.

This book takes you through the facilities that the Angular framework offers, and is filled with examples that can be downloaded from one of the author’s GitHub repository. It starts with a quick introduction to Angular and writes a basic AngularJS Hello World. Chapter 2 goes into directives and controllers, concentrating on an app that displays a collection of data items using databinding and the ng-repeat directive. Chapter 3 covers unit testing using Karma and Jasmine. Angular, with its inbuilt dependency injection makes it easy to do unit testing of your controllers. Chapter 4 touches on Forms and Inputs, and then moves on to the subject of services which are covered in more detail in chapter 5, where the authors discuss the differences between services and controllers.

Chapter 6 covers HTTP communication with the server and Chapter 7 discusses unit testing the server calls that your application is making. Chapter 8 covers filters and Chapter 9 covers how you unit test them. Chapter 10 discusses the ngRoute module, and how it helps you implement history and SEO for your application. Chapter 11 goes into directives in more details and Chapter 12 covers how you unit test them.

Chapter 13 covers directives in more details, and covers the Angular life cycle, such as the digest cycle, in more detail. This is followed by Chapter 14 that covers end-to-end testing using Protractor, and the final chapter gives some guidelines and best practices.

I thought this book was a good introduction, and it was good having the examples to play with in a browser on my laptop. I enjoyed the details about how the framework worked at the low level, and it was good that the authors demonstrated how you might convert a downloaded JavaScript component, a slider, into an Angular component.

While I was trying to get a deeper understanding of the Angular framework, I came across this sample chapter from the book  Build Your Own AngularJS by Tero Parviainen. The chapter seemed to explain some of the details that I needed to understand Angular a bit better, so I bought the whole book. I’m very glad I did. The book is great from the point of view of understanding Angular, but also as a means of getting into JavaScript development. The author develops a variant of the Angular framework in a test driven fashion using npm and its associated libraries.

You get over a thousand pages of detailed JavaScript development which works through most of the features of Angular, starting with Scopes, which were covered in the sample chapter I linked to earlier, and moving all the way up to directives. The whole book is thoroughly interesting and the author explains the framework very well. Moreover, you can work through the examples too by downloading the code from the author’s GitHub repository.

There is really nothing like implementing something to get an understanding of how it all works. The book covers the whole dependency injection framework that underlies Angular in great detail, and mentions features like decorators that were only sparsely covered in the higher level book. The whole dependency injection idea makes the framework very customisable, and it’s great that the whole system is built upon this framework with all of the system components being made available by dependency resolution. Moreover, the Angular implementation of promises was much more understandable when we got into the low level implementation details – particularly promise rejection, and the underlying implementation of deferreds. I can’t recommend this book enough.

There are also a number of good Angular podcasts around including Angular Air and Adventures in Angular. And for a very brief introduction there’s Dan Wahlin’s AngularJS in 20 minutes.

Posted in Uncategorized | Leave a comment

Some interesting .NET videos

Channel 9 have just published a great video with Mads Torgersen. In it he covers some of the features of C# 6, mentioning the new FormattableString class to which an interpolated string expression can be cast to in order to access additional functionality. Most of the video is about some potential C# 7 features, which include pattern matching and valuetype tuples  whose type includes the name of the item in the tuple. There will be work on improving the performance of structs by allowing the return of structures by reference. There is also talk of more research into reference types that do not include the null value. Torgersen also touches on the expression problem when discussing the emphasis on including more functional features into the language.

On a related.NET note, there’s this recording of David Fowler talking about the internals of the new ASP.NET. He follows a request as it makes it way through the new platform, including a dive into the internals of the new Kestrel web server, which uses libuv to allow the same code to work on Windows and Linux. The leastprivilege blog had a recent post that looks at authorisation in this new framework.

Its also interesting that people are starting to submit pull requests for language and CLR changes – examples include pull requests like this and this.

Posted in Uncategorized | Leave a comment

Adaptive Code Via C#: Agile coding with design patterns and SOLID principles

Adaptive Code Via C#: Agile coding with design patterns and SOLID principles by Gary McLean Hall

This is very much a book of three parts – a section named “An Agile Foundation” that covers basic scrum and some of the basic principles of modern software engineering, a section going into detail about each of the SOLID principles, and a section called “Adaptive sample” that tries to demonstrate how the techniques in the book might be used across a number of sprints, by describing two sprints worth of development on a chat client.

The first section is an introduction to agile practices. There is an introduction to Scrum which covers the roles and phases of a scrum project, emphasising how interaction with the customer drives the development process. This is followed by a chapter on dependencies and layering which goes into detail about how you should manage your project dependencies and even gives some brief coverage of topics such as aspect-oriented programming. Chapter three goes through interfaces and design pattern, showing how useful interfaces can be in the .NET world. Chapter four covers unit testing and refactoring – these two items are closely related as the tests give you confidence that refactoring have not broken anything, allowing you to tidy working code without risk. All interesting material which includes some good observations.

The second section of the book, and by far the majority of the book, covers writing SOLID code. The author takes each of the solid principles in turn with a chapter on each. The author discusses the meaning of the principle and then demonstrates its use. On the way there’s often lots of additional material. The chapter on the single responsibility principle, for example, has a lot of extra material on the decorator pattern, showing how they can be used for logging and the introduction of asynchrony, and the chapter on the Liskov substitution principle has some material on pre- and post-conditions. This section of the book is really very good.

I was less convinced by the adaptive sample. We follow conversations between team members as they write a simple chat application. This covers the initial planning for a sample application, and then the team carries out two sprints. The code is available on github so that you can follow along, but it felt like a lot of effort to understand the requirements and the way that the team was working.

The first two sections of the book are really good though, and I certainly learned something from each chapter.

Posted in Uncategorized | Leave a comment

Modern C++ Design: magic with templates

Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu

I’ve done some C++ programming in my time which has required me to write some small simple templates. However, just before going on holiday I noticed this book on the work bookshelf and thought it deserved a read. In the past, I’d come across posts implementing simple functions such as Fibonacci in C++ using templates in a way that gets them evaluated at compile time, but this book takes this much further and shows the tremendous power of type level computation during the compilation phase.

On reading the book, one important message came through – there’s a pattern matching functional language embedded into the C++ compiler which can be used to do some truly impressive feats, including many instances of compile time code generation of highly optimized code. The astounding creativity of the author, and the edge semantics of C++ that are needed to understand some of the constructs, makes this a fascinating read. Though I’m not sure I’ll ever get to use some of the items in the applications that I write.

Chapter one is a great read. The author discusses where features like multiple inheritance and templates fail when they are used on their own. He then goes on to explain where their combination can be very powerful – after all, the template expansion process can generate new classes and can determine how they are going to be mixed together in the multiple inheritance hierarchy. He calls this “policy-based class design”, and it’s a very clever technique. Chapters two and three introduce the main techniques that will be used later.  Chapter two goes through some advanced features of C++ templates including partial template specialization and local classes, as well as ways for detecting convertibility and inheritance at compile time. Chapter three describes a TypeList datatype which is used in many of the techniques to allow template expansion to work through the items of a list of types generating things as it goes. These two chapters are truly fascinating, and I wish I could fully understood all of the concepts that they cover.

The other 8 chapters of the book use some of these techniques to implement a number of patterns – small-object allocation, generalised Functors (the command pattern on steroids), implementation techniques for singletons emphasizing how policy selection allows you to pick implementation trade offs, smart pointers, object factories, abstract factories, the visitor pattern and multi-methods. In each case the author describes the problem, works thorough some of the various design decisions, and then offers several solutions. Many of these solutions build on the concepts in the first few chapters.

I learned loads about C++ in general, lots more about templates and got to grips with ideas around template metaprogramming. Some of the design discussions are also really interesting. Brilliant!

Posted in Uncategorized | Leave a comment

CLR Load contexts can make things confusing

I’ve never really spent a lot of time thinking about CLR binding contexts, but a colleague at work had a problem related to them that took a bit of thought to figure out. These posts, one on stackoverflow and one related to why adding to the private path of an AppDomain has been deprecated, help explain part of the issue and also why there is (maybe) a need for different contexts.

My colleague was writing a Visual Studio extension. The extension was loaded by VS, and his code created a new AppDomain and used remoting to create an application object in the AppDomain. He tried to cast the result of CreateInstanceAndUnwrap  into the type of his remote class and got an InvalidCastException.

After some investigation it turned out that this was a problem with type loading. The returned transparent proxy needs to validate the cast that is being made, which it does in the following methods (which were part of the stacktrace I grabbed using WinDbg and SOS).


The issue was that the initial assembly was loaded using LoadFrom, but when remoting returns a type it is going to be loaded into the Load context as remoting will use the name of the type to try to find it. This is essentially the same effect that you get if you run the following code:

var assembly1 = Assembly.LoadFrom(
   @”C:\Users\clive\documents\visual studio 2013\Projects\ClassLibrary3\ClassLibrary3\bin\debug\classlibrary3.dll”);

var fullName = assembly1.FullName;

assembliesLoaded = new List<Assembly>(AppDomain.CurrentDomain.GetAssemblies());
Debug.Assert(assembliesLoaded.Any(assembly => assembly.FullName == fullName));

assembly2 = Assembly.Load(fullName);

The assembly is part of the AppDomain’s assembly collection, but you cannot load it by name using Assembly.Load. In the above code we get a FileNotFoundException, which is the underlying exception that causing the cast to fail in the remoting example.

What’s the fix?

Well we have the assembly object in the collection of Domain assemblies, so we should just return it if the assembly resolution fails. If we add the following code in front of the Assembly.Load, then the assembly is loaded as expected.

AppDomain.CurrentDomain.AssemblyResolve += (o, eventArgs) =>
var assembliesInDomain = new List<Assembly>(AppDomain.CurrentDomain.GetAssemblies());
return assembliesInDomain.FirstOrDefault(
assembly => assembly.FullName == eventArgs.Name);

Essentially, we take control of the load resolution in the case where the CLR is trying to protect us by using the different contexts.

Posted in Uncategorized | Leave a comment

Some UWP and a little ClojureScript

I’ve been following Lucian Wischik’s interesting series of posts on writing Windows 10 applications in .NET. While I was on holiday he posted an article on writing NuGet packages for UWP but unfortunately the article was removed from the web site when I was only half a way through it. The place holder mentions that the NuGet team were going to talk about the issues and, sure enough, a post has now appeared on NuGet support for UWP in NuGet 3.1. In summary you will now be able to declare project references using a project.json (in much the same way as ASP.NET 5 projects). This will also use the transitive references idea, where you list only the top level projects that you require, and NuGet will take care of fetching their dependencies (and also resolve the appropriate versions when there are conflicts), in contrast to the current model where dependencies of dependencies make their way into your packages.config.

In other news, David Nolen has just announced on his blog that ClojureScript, the variant of Clojure that uses JavaScript as its target language, can now compile itself. Having been through the bootstrapping process myself for both ML and Common Lisp compilers, its always very satisfying when you can get rid of the other implementation, and finally get the compiler to work on itself. His post is rather cool, as it embeds some of the implementation of the translation process into the actual post, and you can run these in the browser that you are using to read the post. Some of this work sits on top of reader conditions, one of the two key features that were recently added to Clojure 1.7 (the other being transducers).

Finally, if Windows Update fails to install Windows 10 repeatedly), then this post has the answer, or rather it works for some people. For me, the relaunched Windows Update failed again, so in the end I needed to manually download by following this link.

Posted in Uncategorized | Leave a comment

C# await inside catch and finally leads to some interesting semantics

I remember when await was introduced into C# – the feature took us away from the callback hell that was developing, but it also required some understanding of the underlying code generation to really see what was going on in simple looking code. The abstraction led to a few rather confusing effects, such as always throwing the first exception of an AggregateException in the await.

At the time people were interested in why you couldn’t use await inside catch or finally blocks, and the answer always came down to confusing semantics. In the recently released C# 6, await is now available in catch and finally blocks, so the question is how this has been achieved without breaking the existing semantics. And I think the answer is that the semantics of some C# forms has now been changed in a way that again requires knowledge of the underlying transforms to understand.

Let’s take the async version of the standard thread abort construct. The call to Abort() notionally throws a ThreadAbortException which can be caught and processed by catch and finally blocks, but which has the interesting semantic of being re-raised when the processing block finishes (unless you reset the abort).

static async Task AsyncVersion()
Console.WriteLine(“Can’t stop me!!”);
Console.WriteLine(“After abort”);

We can explain the behavior of this code fairly easily. The Abort throws the ThreadAbortException, which is caught by the finally block. This finally block prints “Can’t stop me!!” and then the exception is rethrown when the finally block finishes. Hence the “After abort” is never printed.

Now change the finally block to

Console.WriteLine(“Can’t stop me!!”);
await Task.Run(() => Console.WriteLine(“Next”));

When you run this version of the code nothing is printed, and it’s hard to understand why without looking at the code generation. The async method is translated to a class that implements a state machine and, crucially, the finally is no longer a finally in the generated IL code, but is instead translated to a catch block that handles all exceptions.

Reflector shows us:

catch (object obj1)
obj2 = obj1;
this.<>s__1 = obj2;

ie the finally isn’t processed as a CLR finally, but is instead translated to a catch which re-enters the state machine processing. Of course, this means that the ThreadAbort exception which is rethrown at the end of any catch block is going to be rethrown too early, avoiding the exception of the code in the finally block.

I can see that it is a benefit to be able to await in catch and finally blocks, and I guess we’ve had to accept in the past that C# is not the assembly language of .NET. However, the code generation approach to implementing these high level constructs means that sometimes we can see through the abstraction as we can here. I’m not quite sure how important that is.

Posted in Uncategorized | Leave a comment