Monthly Archives: July 2014

So I’ve recently finished the book “Growing Object-Oriented Software Guided by Tests” which in general is a good book except for the major reservation I have for it – it talks about Java, and trying to implement what they say in Javascript isn’t really 1:1, especially due to the lack of contracts. In general I don’t like interfaces and contracts as you can’t tell which implementation was actually used, while Javascript requires a different state-of-mind which covers this aspect: since I don’t know which JS file was loaded or not – there is no contract, I just hope the right library was there to catch the call. I know not knowing if the call was answered sounds worse than not knowing who answered it, but in Javascript it makes a lot of sense and the dynamics is one of the language strongest features.

But I did learn some great things from this book, such as “Domain separation” – each Class (in my case it’s the xxProcess.js files) should handle one domain and not care about anything else – it shouldn’t care what DB will be used or how the output will be used – only what’s the input and what’s the proper output. It actually was like this before where the only change I made in the code in this regard was to extract “Comments” function to a new process file.

Another thing was to have descriptive function names for test so you’d know exactly what this test is running. I had a testProcess before which I didn’t really use. I’ve added Qunit in and created a simple mechanism to run the tests from the console. I removed the testProcess and maybe I’ll add it again in the future.

I now came the big dilemma. I had tons of code to test-unit and it’s sisyphus, especially as I know that i’s working on all cases I might write a test. Test should be something that might fail and break something else down the chain, but as I mention, javascript don’t really have a chain. On the other side, I have a DB integrity issue. It goes like this – in order to do some developing on my local machine, I externally-edited the DB and changed the ownership on some comments and rewired them to different posts. A comment have actually two parents – the topic and the parent-comment, but because of my manual edits, I have some errors there now. Once I realised that, I updated the code so it would log an error and ignore that comment. I’m not too concerned about this scenario because something like this shouldn’t happen in the production. or should it? how can I make sure that another unforeseen event won’t take place? what test exactly should write?

So it came down to this. Yes, I wrote the testing-platform which works great. Yes, I wrote some tests into it. Yes, I know I should use it from now on. But then, for the next major development, I didn’t use it – I didn’t write any test before or after making a huge change and I’m quite sure my new code works great, Because I fiddled with it and any test I might have written – I also checked it myself. Took me a lot less time, I’m sure. This is something that actually bothered me in the book – how much time do they spend writing the test? yes, writing test is important, I’m not saying it doesn’t – but the longer you spend writing test – the more probable you’ll have bugs in the test-code and you’ll spend hours to fix your tests instead of just continuing to write the code.

So yes, I promise that from now, I’ll try writing more tests as part of the design process. While writing this I’m fully aware that I’m lying, which is kinda sad.


So I spent some time this week to fiddle with Angular.js. They have a great tutorial worth checking out. But truth be told, I really didn’t like it and as far as I’m concerned, I don’t want to work with it in the future. I’ll tell you why:

  1. Angular doesn’t tolerate full separation between structure, code and style
    I believe HTML should be clean from any javascript code and any CSS styling (with the exception of expediting the loading procedure). full- separation allows you to replace any of the segment easily; it saves you the need to go look where some JS code was written (in the JS file, obviously!); it help you split the job to several people where the only API between them is ID for JS and classes for CSS. full- separation helps you write better code.
  2. Angular works only on client side
    Sometime the javascript is disabled, or the JS file simply failed to load. what will happen? will the user gets some unreadable information or maybe we can serve him with the bare minimum he actually wanted to read in the first place? Also, how much time will it take the page to load? wouldn’t it be better if the important data will show up instantly and only afterwards the FX will load up?
    The great benefit in using XSLT for templates is that it can be rendered on both client-side and server-side (and by any language!), so you don’t need to write the code twice.
  3. Using angular template means making an extra call to the server
    Each call to the server has a lot of overhead and slows down the page-loading. This is also true for client-side XSLT, but the big difference is that one XSLT can hold many templates (so you’ll get 1 additional call) while in Angular, each template is a file on its own (so you’ll get a gazzilion calls. Lucky for you they’re cached).
  4. Angular encourages user to invent new HTML tags
    That might sound great because the developer can easily read the page skeleton but as a designer it’s bad, because you can’t tell what are the HTML elements formulate the new element. for example:


    while this version maybe less readable, but contains the same information and is much more easy to understand:

    <ul class="products">
    	<li class="product">...</li>

So I prefer to stick with my XSLT, which works on both client and server sides and can be used by any language and is provides better performance than Angular.JS (less calls, computes on the server)