How to properly collect AWS EMR metrics?

Posted on by — No Comments ↓

Working with AWS EMR has a lot of benefits. But when it comes to metrics, AWS currently does not supply a proper solution for collecting cluster metrics from EMRs. Well, there is AWS Cloudwatch of course, which works out of the box and gives you loads of EMR metrics. The problem with CloudWatch is that it doesn’t give you the ability to follow metrics per a business unit, or a tag, only per a specific EMR id. This simply means you can not compare the metrics over time, only for specific EMRs. Let me explain again the problem. A common use of EMR, is that you write some kind of code that will be executed inside an EMR, and will be triggered every given amount of time, lets say every 5 hours. This means that every 5 hours a new EMR, with a new ID will be spawned. In CloudWatch you can see each of these EMRs individually but not in a single graph, which is defiantly a disadvantage. Just to note, I am referring only to machine metrics, like memory, cpu and disk. Other metrics like jvm metrics or business metrics, are usually collected by the process itself and Continue reading How to properly collect AWS EMR metrics?→

Best code convention syndrome

Posted on by — 2 Comments ↓

Developers often tend to think that one coding convention is better than another in terms of readability. Some people think that adding a break before the curly braces is more coherent. Some like camelCase, some hate it. The fact of the matter is, there isn’t any proof that one convention gives better readability than another. Now don’t misunderstand me, I am all for coding conventions, coding conventions are a good thing, but the holy wars for which convention is better seems redundant to me. If indeed one format is better than the other, it has a lot less affect on your performance than you would like to think. The truth is that the convention you prefer gives you better performance simply because you are used to it. The best format to use, the one that would give best results, is the one that you are most comfortable with, even if it is not the best one (if there is indeed a best one). The way our brain works is it always searches for familiar structures to make it work less. When you read a piece of code, your mind finds templates which exists in your memory to ease the job Continue reading Best code convention syndrome→

jQuery Deferred – one step closer to desktop apps

Posted on by — 1 Comment ↓

Every time I forget why I like jQuery, they keep reminding me. Not too long ago I came across jQuery deferred (even though it was added already in JQuery 1.5) and I immediately liked it. I feel this feature brings the web application development a bit closer to the desktop development. Deferreds simply let you add multiple callback to long lasting operation calls like Ajax requests. Long lasting operations without JQuery Deferred If you haven’t used deferreds, this is probably how you had done long lasting actions like ajax calls. Long lasting operations like ajax require a callback function. In this case the callback is given as a parameter to the caller. This is fine, but there is a way to add a callback separately from the call. Try it This is actually the simplest example of using Deferreds. JQuery ajax methods (get,post,ajax…) return an object which you can add callback methods to it. Why is it better? Simply because it lets you keep the logic of execution and the logic of the result separated. This makes a more readable and maintainable code. So what is a ‘Deferred’? Deferred is an object which lets you add multiple callback methods to Continue reading jQuery Deferred – one step closer to desktop apps→

JavaScript encapsulation & the module pattern

Posted on by — 5 Comments ↓

Encapsulation is one of the key features of object oriented programming languages. In languages like Java, it is very straight forward concept to implement. Since I know JavaScript is considered an OO language, I decided to try to understand once and for all how to implement encapsulation in JavaScript correctly. Let’s say we have a function with one private field and one public field: Try It The fields are of course undefined since we need to call f1() in order for them to have values. Now let’s create an object from that function: Try It After instancing, x and y both have values, but of course, only y is public. Now lets encapsulate field x. Try It This is the most basic encapsulation and it works. But this approach has a problem, f1() is in fact a kind of constructor. Whenever an instance will be created than the getter method will also be created. This approach is not the preferred way to create methods in JavaScript. The preferred approach in JavaScript is to create the methods attached to the prototype. In this way they will only be created once. But this approach also has a problem, we cannot use it Continue reading JavaScript encapsulation & the module pattern→