Decorators are quite useful in Angular.
If you are not familiar with their usage, let’s say that they allow you to extend or overwrite a service (or directive or filter) in specific parts of your application without modifying the original one.
One of the advantages is that you don’t have to change too much of the implementation or your in-page code, but every part of your application will use the correct (decorated or original) version of every component.
If you need more information about decorators in Angular read the official documentation here
If you need more information about the decorator pattern in general you can find something here
i18n is the internationalization module provided by Angular: it is really useful for multi language applications as it offers an easy management not only for your labels, but calendar and currency as well.
Even if there is not a strict relation between Decorators and i18n, it’s quite possible that in multi language applications you need not only different translations, but custom rules depending on the language/country and in that situation the decorators come in handy.
Few months ago in the office we started a discussion about testing.
The original topic was “how to implement a continuous integration/continuous delivery workflow”, so “how to test” became immediately a requirement and a parallel important topic.
My suggestion was to start coding in TDD of course, but like every office we had a lot of legacy code to deal with.
In order not to be stuck by that, we decided temporarily to focus on new (or almost new) projects and apply it to them.
So the point became to find a way to have all the developers, regardless on the seniority and the project, on the same page about the topic.
After the first implementation of the game, my friend and I compared our versions.
He focused on the deck model instead of the dealer like I did.
This simple choice drove his design to a complete different path.
He put a lot of effort trying to replicate a realistic deck, implementing the shuffle logic and making impossible to draw the same card twice.
This hypotheses never came up to my mind because I knew that in the real game there are multiple decks in order to make almost impossible for the players the calculation of the drawn cards.
Speaking to a friend a couple of weeks ago, he told me about an interview he did where one of the challenges was to create the blackjack game.
The algorithm itself is not too complicated, but it’s a good test to practice TDD and having never tried it in AngularJs I decided to give it a shot.
If you read the introduction to angularjs, it’s stated clearly that angularjs can be not the best choice to create games.
I can imagine the reason easily: the performances can be very problematic, mostly if the game requires a complex DOM.
Moreover a lot of good frameworks exist to create amazing games in html5 (have you ever heard about impactjs?).
Nevertheless I have found very fascinating the idea to manage via directive a level design instead of a classic multidimensional array as I did in the pawn and tiles experiment.
“Keep it simple” is a good advice, but sometimes it is not so easy even in projects very small.
Just for fun I have tried to recreate a Memory game in AngularJs.
As a kind of game it is not a complicated one, but it was interesting for me to evaluate the time needed in coding using the framework.
The memory game is quite famous among kids, but it is enjoyable even for the adult persons (http://en.wikipedia.org/wiki/Concentration_%28game%29). Continue reading
On the server side is absolutely normal to decorate your Controllers or Actions with the Authorization attribute in order to manage correctly permissions and access to the resources/routes.
Sometime the problem is to manage the permissions or the roles in a much more atomic way in the views.
The scenario that a friend described to me was: I want in the a page to show/hide or enable/disable parts of the it depending on the roles of the user.