Constatus - Find those Strings and Const'em!

Whud'up?

Not so long ago I've opened a random file on the code base I'm working with and saw the horror of many Strings values which have "why am I not a constant?!" written all over them.
I figured that a re-factor is in order but I wondered how will I know that if covered all the instances of a particular String value?

Good thing there is NodeJS around and some nice modules like Esprima, which can help with that, and so I found myself coding this little harmless tool which does the following:
Goes over the code and finds Strings which, according to configuration, should be made constants.

Deadly simple and dare I say dumb as it gets, but guys - it does the work, so why not put it on Github? ;)
So feel free to visit the project on Github with the mind-blowing name: Constatus
It is not complete, there are many more features that can be added, but it's out there for you to abuse ;)

Take care

New Quake-Stats improvments

Yeah, I know - it has been a while since I wrote but trust me, I had important things to attend to, and still do BTW ;) don't worry, it has nothing to do with work, code or debugging shit.
Anyhow - I just wanted to let you know that the "quake-stats" open source application has gained some nice new features!
For those of you who don't know what I'm talking about, you can read about it here and of course visit the Git Hub repo.

So, we got MongoDB into the stack and so we can save games across time. Hold your horses, this doesn't mean that we have over-time game statistics but it means that we're on the way going there.
If you want to upload games files into the application there is an "easter egg" for you. Just go the to "/admin" route and before you will reveal itself a nice upload screen (well, not so nice but it does the work). Once uploaded, the game will be stored on your MongoDB and later can be accessed easily via the "Game" dropdown menu. This great feature is a contribution of Haim Litvak. Cheers mate!

I also added another feature to enable Quake scores over maps per a single player. This feature will display the score Quake calculates for each map and display it on the "player" screen under the "Kill, Deaths & Q-Score" chart.

That's it so far. If you think something is missing, fork it and do it yourself :)

Cheers

My Sublime Text plugins

Yo.

I am pretty sure that many of you are familiar or even using Sublime Text.
If you don't you should definitely check it out and consider it being your main text/code editor.
One of it's key features is the plugins you can add to it, and so you can find numerous plugins which helps your coding process so much. I would like to share with you the very limited, yet so useful, set of plugins I use:

AngularJS
Something to help you code Angular better. Aside from code-completion it also offers a cool "goto definition" which helps greatly within AngularJS. Not to die for, but does makes things easier.

Brackets Highlighter
The name says it all. You want to know where you brackets start and end, surely if you're a web developer. This plugin hands it to you so you can stop looking for that missing bracket.

Git
Runs the basic Git operations from within Sublime Text. I'm not using this excursively since I prefer Git bash for these sort of things, but adding files, diffs and blame are darn easy and clearer with this plugin.

Git Gutter
You want to see your changes directly on the code (ok ok, on the code pane gutter). This plugin will let you do that. love it.

That's it.
Told you, I don't stack plugins just for the sake of having them. These 4 are the ones I use frequently and they are reliable.

I would love to hear any other plugins suggestions you might have that can make the work of a web developer much easier with Sublime Text.

… and BTW -
I don't know how many of you remember one of the brilliant Flash talents of all times - Mr. Grant Skinner. Anyhow, he has migrated to HTML5 development since and recently I've bumped into his RegExp tool for JS. I loved the previous version of that tool for ActionScript and this one is even better. A keeper.
Check it out - regexr

CrunchBang rocks #!

I'm not a Linux power-user. Correction, I'm not Linux user.

Seriously, I spent a lot of time laughing at those Linux fanatics, and still do. It always seemed to me that the more one likes Linux the more s/he has bad social skills.
But one thing has to said - Linux is a better OS for developers, period. If you're building stuff, if your'e contributing code to open source projects, if you like your shell to be efficient - it's Linux, mate.

So I found myself knocking on Ubuntu's doors and working for a fairly long time on it, struggling with it the way only a Win-OS user can.
Yet, something really bothered me with Ubuntu. The way it tried to be user friendly and in that course fucked up the UX or the way it offered me so many advanced features which I didn't want or cared about.

I have an old Toshiba Tecra laptop. It served me through thick and thin, suffered my abuses and even overcame some nicely done floor-crashes. I call it "the gimp", and my "gimp" had 2 OS's installed on it when I decided that it is time to wipe it clean and install a single one which can perform nicely.
Ubuntu was obviously the first choice, but then I can across a nice resource which presented a new linux debian distribution called "CrunchBang", or as the natives call it "#!".
After little exploration I came to know that it was a very light-weight OS, which works nicely on old machines - I had to give it a go.

The installation went briefly and in a matter of minutes I had it in front of me.
The interface minimalism is what got me first. No more task-bars and shit, just a blank desktop with the system monitors on and a set of keyboard shortcuts. beautiful.
Everything went faster, from opening the web browser to utilizing git on the shell - if it was a comics strip, I would add "SWOOSH!" to every operation I've made. And guys, I'm talking about and old machine with 3G of RAM and 2 Cores CPU. Insulting shit in today's terms.
I also have to mention that Ubuntu didn't approve my 2 monitors settings, which kinda sealed it's fate for me. What? install a plugin for that? yeah, right...

Of course I had to tweak the OS (yet) again, installing JAVA 1.7 (com'on, why does it have to be so annoying?!), installing languages and stuff, you know. But once I've done doing that, I was faced with a swift OS. simple as that. The "start" menu accessibility, the way OpenBox works for this OS, Sublime Text flying like an eagle over it... just sweet.
Imagine how it would perform on a new machine...

So if you're looking for a cool Linux distribution for your old machine, or just a cleaner OS which performs like a devil on the 7th pit of hell - I recommend you give this one a go.

… and BTW -
I caught this very inspiring deck of slides from HubSpot describing their culture. It's interesting to see how companies are aligning themselves to fit the present time.

Printing a Dialog content using Canvas and iFrame

Hi guys,
You know that printing from the browser is a bitch. Even after you've figured out how to put the content you want into the browser, the printing doesn't always work the same on all the browsers (yes! HTML is a standard... my arse). And that's not where all the trouble stop but anyway...

The problem I would like to bring up in this post is printing from a dialog box, which is more complex since we have to somehow extract the visual data from the dialog and then put it in some way that the crippled window.print() method can make sense of it. I mean seriously, have you ever seen such a lame API? print()? that's it? no "what do you want to print?". Throw me a freaking bone here.
Given that we're dealing with a dialog kinda eliminates the possibility to use the print media query, since we're not going to alter the whole page, just a section of it.

I saw many solutions on the web, some offering to save and then clean up the DOM, attach a cloned version of the DOM you actually want to print, and then re-render it all back after printing, which to me sounds like "bla bla bla bad performance sad users bla bla bla".
You know, all kinds of adding classes to elements, removing it then later... oh god.
Of course there is the jQuery plugin which offers to do that but I wasn't in the mode to introduce yet another jQuery pluging so I had to think of something else...

Canvas came to the rescue.
The idea I came up with is to somehow capture the DOM content I wanted to print, convert it into an image, and then create a hidden iFrame bearing the content of this image among other stuff I wanted to be printed. How? canvas can be concerted into an image.
I already had html2canvas library so it wasn't in a need to download any other 3rd party. you can get what it does from it's name, right? good.

Moving forward, here's the actions the code needed to perform (pseudo-code):

• Get the canvas from the HTML elements
• Convert the canvas to an image using the toDataURL('image/png') method
• Create an iFrame dynamically
• Append the iFrame to the DOM 
• Once loaded Set the iframe content with the newly generated image I have
• Send it to printing, by printing the iFrame content only
• Smoke a cigarette

I believe that what's written above should give a good idea on how to implement it.
As for printing the iFrame itself I took a code snippet from some stackoverflow thread but I had to tweak it a bit since Firefox didn't like what I did, for it removed the iFrame before the browser launched it's printing. To overcome this I've used a deferred object, like so:

this.printIframe = function (id) {
var deferred = $q.defer(),
    iframe = $window.frames ? $window.frames[id] : $window.getElementById(id),
    ifWin = iframe.contentWindow || iframe;
ifWin.focus();
ifWin.print();
deferred.resolve('done');
return deferred.promise;
};

and this means that I had to listen to the promise in order to remove the iframe from the DOM and not just count on the fact the window.print() is supposed to stop javascript execution...

I think that pretty much sums it up. It might not be the best idea out there so I would love to hear your opinion on it or better if you have a better one.

… and BTW -
I caught this nice AngularJS Weekly magazine (or whatever you would like to call it) on the way. A lot of cool resources and stuff. Pretty nice.

Stay tuned and play on.

All the JS you need

Yo guys,
You know me, I'm just strolling around the web bumping into nice stuff on the way, and recently I found a great place where you can pretty much get all the knowledge sources you need for JS.
To be honest, it's pretty amazing how much one can gather about this Egyptian-pyramids-fucking-papyrus-deserved scripting language, but then again we must, now don't we? :)

Enjoy it: superhero.js

Delegating Event handlers to align Event Data model

After such a pretentious title we can all stop and take a one week sleep. WTF do I want from you now, you probably ask. yeah, ok. check this out:

Think about this next situation - You have a nice component which potentially can host several other components, each can dispatch a different event, an event that needs to be handled of within the "parent" component.

We cannot let the "parent" component manage all the events potentially fired from its nested components, right? I mean, we can let it but then we will pretty much shit into our own development experience and maintenance, after all, we want the "parent" component to be aware of a single Event data model.

Being aware of a single event data model means that the "parent" component will expect a single format of data when receiving events from any of its nested components. It will not matter what's the data model of each nested component, something will have to align it into a single well-known model. The question is who?

We need some kind of a delegator, which will know all the potential events and will process their data and send a nice formatted data back to the "parent" component.

So, if we are to drill into more details, we're actually talking about extending the "parent" component's Scope, since it is that Scope which will eventually listen to all these events, but it will be done in a sort of a "mixin" approach.

The solution I came up with introduces a service which has a single method registering the "parent" component's scope. From there on, the service will extend the Scope and eventually send an event back to the "Parent" component with the processed event data.

Simple does it.

 

The POC can be found in Plunker

I would love to hear if you have any comments about it.

Cheers

My Unit Testing Approach to JavaScript

Hi guys,

I thought it would be nice to share with you my approach to JavaScript unit testing.
It's not really bound to any particular technology so you can embrace it if you think it can bring you some peace.

• Configure a threshold time of each test to be less than 500ms. I hate to wait on code. I need feedback now.
• I feel really bad when I need to write test for a already written code. It misses the whole purpose and usually results in bad testing. I thrive to always write tests first and code later. Close the gap you have, and start working the right way.
• Start from high-level "it"s describing what you want to test do check, so the result will be a set of empty "it" functions describing the expected functionality.
• Launch a watcher on the test files. This is crucial for having immediate feedback to whatever you're writing.
• For me, I launch the grunt serve task (Yeoman) which let's me see the application running while monitoring the tests. The Karma runs as a part of it and while keeping the autoWatch parameter as true, each save is triggering the tests. I'm always testing and seeing that the application doesn't break.
• Writing minimal code to fix the test is so important. We, developers and mostly architects, have the tendency to think far and beyond. Stop it. I'm fixing only what is required. At least I try to… ;)
• If I see that a group of tests should be bound together under some functional context, I do that by adding nested "describe"s.
• I'm always making sure that the description for the tests make sense as a real sentence which anybody can understand, even fishmongers.
• Test is first citizen code. Have JSHint/JSLint prob on your test code as well. 
• I want to see my coverage all the time. It gives me satisfactory and a warm pat on the back, but seriously now, I got to have some indication as to how good am I doing and whether I cover all the branches important to me. 

Do you have a different approach?

… and BTW -
I've bumped into this nice online tool which helps assessing 3rd party JS libraries.
Check it out at jscritic

Stay tuned.

Mocking a Confirmation Dialog in AngularJS Unit-Testing

What is more convenient then talking about the shallow gratification tests give us in the previous post, and now posting about testing examples. What can I say, you got me, I'm a child ;)

Anyhow, lets take the following case: User wishes to delete some book from his library, once he presses the delete button a confirmation dialog pops up to ask him if he is stupid or not, and once he approve that he is, the entity is being deleted.

Now, some of you may jump and shout that this is no unit! this is an automation test par excellence, but I would have to shut them up and say that yeah, this should also be tested in automation but there are unit aspects that need to be checked as well. let me explain-
You controller will probably contain 2 methods:

• confirmBookDeletion - which pops the dialog
• deleteBook - which actually deletes the book

In my unit testing I would like to cover both methods. so basically, the "deleteBook" is the easy one, where you simply expect DELETE on you $httpBackend, but the tricky one is the confirmation.

If we will break it down, the process is: display a dialog with a certain caption to it, wait for that dialog "promise" and act according to the decision (in our case "yes" invokes the deletBook method).
how do you do that? that's right, you mock it. but how?

Obviously you have some sort of a DialogService which makes your work mach easier, and on it you have a nice "confirm(msg)" method which does what take, but how exactly are you going to mock it? it's not just making sure that DialogService.confirm(msg) was called but it has to return a promise which you can later work with. It's actually pretty straight forward

First thing, let's create a MockDialogService. We do that for the sake of spying after it's confirm method:

MockDialogService = {
confirm: function(msg) {
}
};

So now you can spy on this method, but here is the nice trick - by spying on it you can define what returns when you call it, and in our case we would like to return a resolved promise with the value of "yes" (cause this is what we're testing now):

var deferred = $q.defer();
deferred.resolve('yes');
spyOn(MockDialogService, 'confirm').andReturn({result:deferred.promise});

Now that we have that we can make our expectation from it, like so:

expect(MockDialogService.confirm).toHaveBeenCalledWith('Are you out of your mind?!');

Nice. Now we need to see how this invokes the deleteBook method. so we spy on it:

spyOn(yourCtrl, 'deleteBook');

And here comes the tricky part. Since promises will be executed on the next Angular Digest cycle, we need to trigger it. We do this with scope.$apply(). After that we can expect that the deleteBook() method will be called:

scope.$apply();
expect(ctrl.deleteBook).toHaveBeenCalled();

Cheers

Understand why

So - You writing code in a TDD manner, which means that basically you're writing the tests first, waiting on them to fail, and then writing the code which makes them pass.
Damn, This makes you feel so good, right? It's like a fucking rush of satisfactory that runs through you, making you feel like you're fulfilling your roll in the world, you're executing your work to the max. You tell yourself that hey! You can do that forever. No, seriously - FOREVER.
But have you ever wondered why you feel this way?

What exactly taps into our, some-might-claim, childish emotions and pats us so warmly on the back?
Most of us feel this way and usually don't give a flying fuck about the end product, not to mention the end user of the software their creating, and this puzzles me greatly - what makes some of the smartest people I know develop such an addiction to this an immediate, shallow gratification feeling?

Let me try to ware the psychoanalyst hat for a sec and make some assumption on why a developer feels so good about a passing test and try to drilldown to find the true nature behind this behavior

Is it the quality?
Sadly I would have to say it is rarely the quality increase which makes developers so satisfied with a passing test. I saw many tests which don't check anything and pass successfully, leaving their author happy like pig-in-shit with the work he has done. In some cases developers would even knowingly cheat to make a test pass, although they will later claim that this has damaged their satisfaction since our conscience cannot be tricked that easily. Sadly The build can.
Personally I believe that the motivation for tests should come from the desire for quality. Why you desire quality? Because you want your customers to enjoy and have value from using your product.

Is it the game?
Writing software in TDD is very much like playing a self-game. It's like you're challenging yourself, much like playing Solitaire, putting targets and then trying to hit them with a stone from afar. And you have monitoring which kind of represent a leader board where you can see how much targets you did hit (coverage), which sometimes brings developer to an absurd state where their testing meaningless chunks of code like Getter/Setter just to have their coverage up.
The game does have contribution to developers satisfactory, but playing it without seeing the big picture can sometimes distract you from the real goal, that is making the end product better for the user. After all, all your code can be covered with tests and you will be top of the list, but the product doesn't sell because it is a piece of crap. Better start packing your cubical up cause your company went broke, but hey, don't forget to take the leader board with you!

Is it the mini-goals?
You know these lovely "todo" lists? Research have shown that people enjoy "checking" a task as done so much, that sometimes they register task they've already completed just to have a "check" next to it, while other tasks that really needs to be attended are left neglected. You know what I'm talking about… yes, you do.
Same with the tests. You set up small tasks to be completed, e.g. "should fetch user information" and you right away start working on it in order to put a "check" over it. You like it so much that sometime your tests become meaningless and have no benefit to the code quality or maintenance.

Is it our perfectionism?
You love to see thing done to perfection. Most of us who deal with software do (some don't and they should get fired. I mean - now). So you look at your coverage report and you eye starts to twitch for you see that you're missing 3% to your 100% code coverage. You don't mind that the code is well tested and that 3% is redundant and having them tested will not benefit the code whatsoever. You want to reach that 100%. A sheer waste of your time and build time, but damn - I just have to get this thing 100% green.

Tests are not the goal, they are the means
Yeah, let's remind ourselves once again that tests are the means in getting our goal which is a good and maintainable product releases. No seriously, you have to stop dancing around glorifying the hammer you're holding when all you have built with it is a huge pile of horseshit.
And for that matter, I strongly believe that developers should stop alienating themselves from the product. It's not only the tests which are the means but the code itself. It is your means for creation. The paint of your brash, the nail and hammer. We should concentrate on the painting. You have never seen a child showing off his color palate to his parents, right?

So why then?
Because it's easy and well defined.
If you look closely at the tasks you've recently had you'll find it that you tend to avoid those which are hard to complete or those which you have a vague idea on how to accomplish them. Tests are neither. Tests are well defined tasks which are basically easy to complete. Of course you like doing them. Hell, you're even get credits if you make a lot of them.
Why the hell won't you write them like crazy?

Conclusion
Tests are good. Write them. Responsively.
You're not a monkey. Always question the world around you and try to understand… why.