Forms Authentication Sliding Expiration and the SPA

Working on a SPA with Forms Sliding expiration.  The trick is how to let the SPA know the user has timed out.  If you make a call to the server, with sliding expiration enabled... the account will never expire.

I don't have a working solution yet, but thought I would post the observation.

TF-Git

Testing out TF-Git.  The tools for peer review are more robust in the git ecosystem than in TFS.  The workflow seems reasonable so far.  

 

https://gittf.codeplex.com/

Gitlab - Permissions and Groups

When setting up GitLab, before you start using it, be sure to set up a project group.  If this step is omitted, all projects are created under a user account and only that user can check in code. 

I have seen this issue three times now, so I thought I should post this.  This is unique to GitLab and there is not a visible analog in Stash or GitHub.

Do not use RequireJs and AngularJs

Do not use RequireJs with AngularJs.  It is premature optimization.  I have read many posts where they show how to use requireJs.  I have not seen one post that has empirical data PROOVING that using RequireJs improves the overall user experience in any significant way.

I suggest mastering alternative strategies for ng-repeat if you want to optimize something.

I spent a year and a half writing 25,000 lines of AngularJs code with no problems! We were bad developers and did not even minify and consolidating our JavaScript. The JavaScript was in ~30 different files. (We wanted to min and consolidate but the usual tools were not allowed in our secure and constrained environment.)

Most of the noise about using RequireJs is theoretical. I have yet to read a post where a team could not satisfy performance requirements established by the business using AngularJs and had to refactor to using RequireJs for lazy loading.

If the wire is your worry...

• consolidate your JavaScript into one file,
• minimizing that file,
• compress files across the wire

In most AngularJs apps the images are probably larger than the JavaScript.


Even Brian Ford recommends not using RequireJs with AngularJs. http://briantford.com/blog/huuuuuge-angular-apps

I would like to post more on the mechanics of AngularJs and why I feel this way, but time is short today.

Integration testing services with Jasmine 2.0

Testing real services using jQuery and Jasmine took some research. I saw in the docs that I needed to work with done(), but where?  The code below works.

Optimizing Pagination with MemoryCache

In web development pagination is fairly straight forward when using out of the box components. When building custom components on expensive queries, paging is not quick to implement.

The query I needed to implement paging against was an expensive query.  After fighting and fighting, I thought why not slam the whole thing in MemCached and page against the query.  Felt kinda weird about it.  After all this would have been a major fail 10 years ago.  Then listened to Rob Conery on DotNetRocks.  In Robs new project Biggy, he stuffs the whole database in memory using ICollectionOf<T>.  Feeling validated, started down the memory path.

I was not quite ready to use Biggy, but MemCached is appropriate.  MemCached was not setup.  Then found the MemoryCache class in .NET.  There is more than one version.  One for web and one for console apps.  Nice! I mainly wanted to use MemoryCache for the expiration policies.

The performance is significantly faster than the expensive sql queries.  Creating pagination across the collection is very easy using linq.

It has been so easy to code against, I've created a few filters; light search, return only certain fields, or exclude certain fields.

Disclaimer: There is a very good reason why I'm not using an ORM or a document database that does not have this baked in.

Verify Times Once

My first WebApi controller test is usually Verify Times Once as show below.

Repo.Verify(x=>x.GetUser(It.IsAny<string>()),Times.Once);

A new member of the team questioned the value of the test. I agreed it was probably more ceremony than a realistic possible regression.
Later in the day I saw the following property in a class.

 public static IFooRepo Repo { get { return _repo ?? (_repo = new FooRepo()); } } 

The code above is tightly coupled.  I prefer loose coupling.  The property is doing the work of the constructor (assuming we are using constructor injection.)  Changing the property from static to a regular class property allows the developer to override the hard coded FooRepo with a mock repo object derived from the IFooRepo interface providing support for testing other methods.  I think we still have a problem with this pattern.  Given a class with more that one property, how will the developer know which properties need setting and which to leave alone? The developer never needs to guess what properties need to be set when the class uses constructor injection.

It might feel like ceremony to perform an obvious test like Verify Times Once, but it ensures loosely coupled code that supports future TDD style tests.

Called out on the Switch Statement

I was going over TDD with a developer and made a statement that I avoid using switch statements. (I may have used stronger language like "never use", can't remember.)  Then a few days later, I was pair programming with the same developer and I used a switch statement.  The developer, frustrated and confused, called me out on it.  

We were working on parsing XML sax style using xmlreader and writer.  I was also copy and pasting code from the sample as a first pass to quickly get my tests to pass.  If I needed to change... that is what refactoring is for.

While I was chopping wood for the fireplace, I was reflecting on this issue and I came up with the following.  On more than one occasion, I have had to refactor switch statements to either if else statements or, in some cases, a full blown rules engine.

I have nothing against the switch statement, other than it does not leave me much room for refactoring.  The "if" statement is reduced to a boolean in both the switch and if-else.  But in the switch statement one operator immutable throughout the evaluation set.  In contrast the "if-else" allows both sides of the equation to change at each decision point.

The XML example, using switch was fine.  The problem domain is fixed and backed by well established enumerations against a very mature standard.  When I am working out something new on my own, where both sides could change, I stick with the if statement or something else that is more flexible.

TDD and Static Methods

Static methods present a problem in TDD. Interfaces do not support static methods. This can put a damper on fluent interfaces, unless the fluent interface is first developed in a TDD-ish manner and under test, then a fluent interface is put on top of the functionality.  This is usually how it is done anyway.

Especially in TDD avoid static methods unless you have a "good" reason to use them.  Trying to reduce two lines of code down to one for invoking a class, is not a good reason (in object oriented programming.)

NorfolkJs

The very first NorfolkJs meetup tonight. Great group, even had a pair of Google glasses starring at me.

Kevin had good suggestion, next time show filters on repeat.

Also note to self, if it has been a month since doing ng-class. .. brush up before presentation lol.

Presentation was on angularjs.

Went over data binding, controllers, ng-filter, ng-class, karma test runner, jasmine, testing, and a plug for egghead.io for training.

TDD simple definition

Stating that TDD is just red, green, refactor, is like stating all you need to know to perform an appendectomy is make a cut and remove the appendix.

MOQ and out parameters

MOQ does not support out or ref parameters.  This bring up the debate about how testing tools can limit the developers creativity.  In the end testing is important.  There are other ways to accomplish the same goal.  The out parameter is nice but, testing is nicer.

public bool hasPermissions(string context, out List<string> allPermissions);

restructured to 

public bool hasPermissions(string context, List<string> allPermissions);

Not much of a change, but I do blow out all the data passed in.