AppDynamics grouping Database Custom Metric Queries

When you create Custom Database Metrics in AppDynamics, you first thought is to create a new row for each metric, but if you have a lot to report on this can become messy. Not only that but in the metric view you will have a very long list of reports to go through. Therefore when we had the consultant down at work, we was shown how to group collections of metrics in one query, which then shows in the metric view in a sub folder. This tactic, we could not find anywhere on the internet, so I thought I would share this very handle insight for AppDynamics.

Your stand method to add custom queries and metrics would be to go to this view below configuration view in AppDynamics and add new queries for each of the metrics you wish to report on.

AppDynamics Databases

You can then go to the metric view and see the data coming in like below.

AppDyanmics Metric Browser

However, like I said above, this list can grow fast plus by default you are limited to only 20 of theses’ queries, which can disappear faster. Therefore this method gives you more bang for your buck on custom metrics, plus also the organisation of your data.

Instead of adding each query separate, what we can do is create a grouping of queries into sub folders of the ‘Custom Metric’ folder, to look like this.

  • Before
  • Custom Metric
    • Queue 1
    • Queue 2
    • Queue 3
  • After
  • Custom Metric
    • MessagingQueueMontioring
      • Queue 1
    • Queue 2
    • Queue 3

As we, at my company, completed this in Microsoft SQL I will use that as an example, but I would be confident it can be translated to other languages with the same outcome with some slight changes to syntax.

Say we start with the 3 queries that we would want to monitor and we will keep them simple:

SELECT count(id) FROM MessageQueueOne
SELECT count(id) FROM MessageQueueTwo
SELECT count(id) FROM MessageQueueThree

To create the top level folder, you simply create a single query item called ‘MessagingQueueMonitoring’. In this new custom metric query you need to add the above 3 SQL statements, but we need them to be a single query instead of 3. For this to work we will use the SQL command ‘UNION ALL’ to join them together:

SELECT count(id) FROM MessageQueueOne
UNION ALL
SELECT count(id) FROM MessageQueueTwo
UNION ALL
SELECT count(id) FROM MessageQueueThree

This will now create one table with 3 rows and their values, but for AppDynamics to recognise these in the metrics view we need to tell it what each of these rows mean. To tell AppDynamics what the nodes under it are called you add a column to each query for the name. This column should be called ‘Type’ and then for AppDyanmics to know what the value part of the table is, you call that column ‘Total’.

You should end up with a query like below:

SELECT 'Message Queue One' as Type, count(id) as Total FROM MessageQueueOne
UNION ALL

SELECT 'Message Queue Two' as Type, count(id) as Total FROM MessageQueueTwo
UNION ALL

SELECT 'Message Queue Three' as Type, count(id) as Total FROM MessageQueueThree

Then this should result in a table like this:

TypeTotal
Message Query One4
Message Query Two2
Message Query Three56

How to get a PDF from Server Side to Client Side?

So you generate a PDF in the C# code or any back end code, but need to send it back to the JavaScript doing the AJAX request. The trouble is how do you return a file back to the client side, which is the same problem I faced. There are loads of methods of how to do this that I have seen on the line, but these are the ways I found worked with C#.NET and JavaScript consistently.

Returning the File

First method I found was very simple and the most direct route to the user. In this scenario you do an AJAX request from the JavaScript straight to the back end system that is generating the PDF file and return that file in the request.

First get the file from the file system into a ‘FileStream’:

Var filesFullPath = "C:\documents\pdfDocument.pdf";
Var fileStream = new FileStream(filesFullPath , FileMode.Open, FileAccess.Read, FileShare.Delete, 4096, fileOptions);

Then use the ‘ControllerBase.File’ class, part of the Controllers inherited class, to convert the ‘FileStream’ into a ‘FileResult’ with a PDF content Type:

Var fileResult = ControllerBase.File(fileStream, "application/pdf");

‘ControllerBase’ is part of the inherited ‘Controller’ Class from ‘Microsoft.AspNetCore.Mvc’.

You can then return this object back to the requesting JavaScript. On the client side it is just a standard ‘XMLHttpRequest’, but the key part is the ‘responseType’ is set to ‘arrayBuffer’.

This means when the response comes back in that format we can create a new ‘Blob’ from the object with the correct content type. This Blob is then converted to a URL and opened in a new window.

var url = "<a href="http://www.GetMyPdf.com/GetPdf">http://www.GetMyPdf.com/GetPdf</a>";

// Send Request
var xhr = new XMLHttpRequest();
xhr.open('POST', url, true);
xhr.responseType = 'arraybuffer';
xhr.setRequestHeader("Content-Type", "application/json");
xhr.onload = function (e) {

// Check status
if (this.status == 200) {

// convert response to Blob, then create URL from blob.
var blob = new Blob([this.response], { type: 'application/pdf' }),
fileURL = URL.createObjectURL(blob);

// open new URL
window.open(fileURL, '_blank');

} else {

console.error('response: ', this);

}
};

xhr.send(JSON.stringify(data));

Now this works great in the scenario above, but a situation that we came against was the back end code to the client side was not doing the generating there was a middle tier, then also it was handling the response from all APIs as a json response which is a string type. Therefore we couldn’t return the file directly and not in an Array Buffer format.

A better solution would be to store the PDF file somewhere the client side can request it after it has been generated. This will save on the large packet of data being sent back and less worry of data loss, but let us continue on this path anyway.

The solution to the weird request is to use Base64 as the string based response. In the C# code we can convert the file into ‘bytes’, which can then be converted to Base64 string:

var fileFullPath = "C:\documents\MyPdf.pdf";

// Convert to Bytes Array
bytes[] pdfBytes = File.ReadAllBytes(fileFullPath );

// Convert to Base64
var base64Str = Convert.ToBase64String(pdfBytes);

This is then saved to return back as a string to the middle tier and then back to the client side.

We now have a string response that we can to convert the Baset64 into a PDF file for the client, which can work both of these ways.

If you first prefix the Base64 with the PDF Base64 DataURI as below:

var base64Str = "****";
var base64DataUri = 'data:application/pdf;base64,' + base64Str;

You can then open the Data URI in a window:

// open new URL
window.open(base64DataUri , '_blank');

However I didn’t find this consistently working, so instead I do the same as before with the ‘XMLHttpRequest’, but instead the URL is the Data URI.

var url = base64DataUri;

// Send Request
var xhr = new XMLHttpRequest();
xhr.open('POST', url, true);
xhr.responseType = 'arraybuffer';
xhr.setRequestHeader("Content-Type", "application/json");
xhr.onload = function (e) {

// Check status
if (this.status == 200) {
// convert response to Blob, then create URL from blob.
var blob = new Blob([this.response], { type: 'application/pdf' }),
fileURL = URL.createObjectURL(blob);

// open new URL
window.open(fileURL, '_blank');

} else {

console.error('response: ', this);
}
};

xhr.send();

This now uses the base64 string as the URL to request the PDF as a web request so we can return the PDF as a Byte Array, then just like before it is converted to a Blob, to URL and opened in a new window.

So far this has worked and consistently, so try it out and give me any feedback.

Keeping an images ratio on resize in JavaScript

A little tricky task was given to the team I am working in, to keep an image at its aspect ratio. However the catch is that it needs to be able to go as large as it can to fill the screen at all times, while the user can resize the screen and keeping the images size ratio. Easy you may say, but once you get into it, not so much.

Three of us thought long and hard through many different situation of how we can calculate the size, detect the users actions and calculate the ratio, but with no luck. We also then hunted the internet as all great developers do, which produced many methods using some very long calculation, but none just seemed to work and we knew nothing about the maths.

Then like a shine of light I thought of how you can do it in a simple way. Instead of thinking of the image at 1980px by 1020px and then calculate out the pixel difference etc, you need to think about the image in percentages. When you reduce the images width by say 594 pixel, you would then think of how to calculate the relative pixel difference on the height of the image, but this would be going in the realms of mathematicians. Therefore you stop thinking of that in pixels and think that 1980px reduced by 594px, is a 30% reduction.

Now all you need to do is reduce the height also by 30%, relative to the heights pixels, so here we go…

First we need to find out what the width and heights relative 1% is, so we know where to work from. You need to provide the images original height and width to start this off, then divide each by 100, simple maths.

// Get the one percent of the image width and height
var widthOnePercent = imageOriginWidth / 100;
var heightOnePercent = imageOriginHeight / 100;

Next because we want the image to be as large as it can, we will set the width to be as large as the container to start off the calculations. Once this has been set we can use the images size to find out what percentage the width is at. We know the width of what the image is at in pixels and we know how many pixels are 1%, therefore we can divide the images width by 1%. For example 1386px divided by 19.8px equals 70%.

// Calculate the width percentage
var imageCurrentWidth = $(imageSelector).width();
var imageCurrentPercent = imageCurrentWidth / widthOnePercent;

Now we just need to set the height of the image to 70% of the images height, by multiplying the images 1% height by 70%.

// Calculate the height relative to the percentage of the images width
var imageNewHeight = heightOnePercent * imageCurrentPercent;

However this will work to put the image within the width boundary of the container and the images ratio kept in tact, but potentially due to the width the height could be off the screen. Therefore we need to make sure the image doesn’t go off the screen. This can be calculated out by checking if the height of the image, plus the distance from the top of the window, is not as large as the windows height.

($(window).height() < $(imageSelector).offset().top + imageNewHeight)

Once we have determined this, then we do the same as before but in the opposite direction. This time we start with what height we want the image to be, instead of what height it is. To do this we use the windows height, minus the images top offset, which gives use what space is left.

// Set the new height so it fit on the screen
imageNewHeight = $(window).height() - $(imageSelector).offset().top;

Then the same as before, it is divided by the images 1% height to calculate what the percentage the width is going to be.

// Calculate out what percentage is the height at
imageCurrentPercent = imageNewHeight / heightOnePercent;

// Calculate the width relative to the percentage of the images height
var imageNewWidth = widthOnePercent * imageCurrentPercent;

Below is the full JavaScript code, but to see a full example check out my PureRandom CodePen.

(function($) {

function calIamgeSize(imageSelector, imageOriginWidth, imageOriginHeight) {

// make image as big as it can to start
$(imageSelector).width(
$(imageSelector).parent().width()
);

// Get the one percent of the image width and height
var widthOnePercent = imageOriginWidth / 100;
var heightOnePercent = imageOriginHeight / 100;

// Calculate the width percentage
var imageCurrentWidth = $(imageSelector).width();
var imageCurrentPercent = imageCurrentWidth / widthOnePercent;

// Calculate the height relative to the percentage of the images width
var imageNewHeight = heightOnePercent * imageCurrentPercent;

// If the images height is off the page, then rescale
if ($(window).height() < $(imageSelector).offset().top + imageNewHeight) {

// Set the new height so it fit on the screen
imageNewHeight = $(window).height() - $(imageSelector).offset().top;

// Calculate out what percentage is the height at
imageCurrentPercent = imageNewHeight / heightOnePercent;

// Calculate the width relative to the percentage of the images height
var imageNewWidth = widthOnePercent * imageCurrentPercent;

// Set new width of image
$(imageSelector).width(imageNewWidth);

}

// set new height of image
$(imageSelector).height(imageNewHeight);

}

// Resize image
var imageW = 1000;
var imageH = 667;
var imageClass = ".js-render-image";

$(window).on("resize", function() {

calIamgeSize(imageClass, imageW, imageH);

});

calIamgeSize(imageClass, imageW, imageH);

})($);

Should you unit test CSS?

When I told a college I was going to write some unit tests for CSS they went crazy, and I do see why, however I think it can be valuable in the right way. I would like to describe to you why I think doing unit tests on CSS can be worth your time as a developer and also beneficial to the project.

Why oh why you may ask would you unit test CSS? Styles change so often, the style might be abstract from the code and they can be hard to test. You can’t test just the code, you have to test it for what it is, which is User Interface(UI) coding. Therefore you need to test it through the UI with something like Selenium, that boots up a browser and checks the UI. Though even if you use this technology then testing literally the size of the font and the colour of the background, which have no variable changes, you not testing properly.

Normally when you are unit testing, it is on something that can change depending on multiple variables, so testing the font size isn’t that. When you are testing them things they can only change if you want them to, so you not testing the code, you’re testing that you remembered to update the test. For example, if you have a ‘h1′ with a font size ’14px’ and write a unit test to check the browser has rendered a ‘h1’ with that size, then you have a change come in. You change the font size and now your unit test fails, so you update the test case, but what have you just shown to the project? You have proved that the font has been updated in both places.

It also gets hard when you are testing with browsers, as each browser will interpret the CSS in different ways. They render different, so when you test ‘1em’ is ’14px’ you might get a different answer in another browser.

Therefore why do I think you should unit test CSS?

Well that’s more because I am not saying to test the CSS purely, but to test modular items. In the project I work on there are modules in the site that share classes. Things like a promotion box with a background colour and a banner with the same background colour. We use the CSS pre-processor called LESS, so the background colour is stored in a variable shared across the code base. If a developer decides to change that variable for the banner, we want the unit test to flag that changing this colour effects the promotion box as well.

Example CSS:

@bg-color: #66bb6a;

.banner { background-color:@bg-color;}
.promo { background-color:@bg-color;}

This is why we should unit test, because we want to know if a classes style changes then what else does it effect. Imagine the above CSS lines were in separate files. You change the ‘@bg-color’ as you want the banner to be a different colour and then the unit test flags that the promotion box is incorrect. The value from this means the developer can find out what breaking changes they have introduced, which helps them decide it should all change or no I need a new class.

There is also testing where it takes graphical images and compares the two, but this is browser and code structure dependent. You can to make sure you can test the code in all situations and that’s why a banner for example is better than a whole page.

In our organisational structure then CSS is in a separate code base as the HTML it is running on, due to the CSS project being used in multiple projects. Therefore, we can’t test against the project’s code base, instead we need to create a running example each time. This has it benefits as we then have a working example to demo to the HTML developers.

This is where and why I think there is value in doing unit testing on CSS, but what do you think? Do you do it already or do you think it is a waste of time?

How to use Chutzpah with Visual Studio and Build?

If you want to do some JavaScript Unit testing your most probably going to use things like Jasmine, Qunit or Mocha, which are all great things, but how do you run them? This was a challenge I came upon with Visual Studio and how to get it running like a normal NUnit test.

First of all if you don’t know what Chutzpah is, it’s an Open Source Test Runner for JavaScript unit testing frameworks. It currently works with Jasmine, Qunit or Mocha, using the PhantomJS headless browser for testing. You can find out more information on these subjects with the links below:

Visual Studio Setup

To get Chutzpah set up in Visual Studio could not be easier. You simply need to install the Nuget Package from the manager. There are multiple method to do this, but the one I use is this.

  1. Open Visual Studio (version 2013 is used in the graphics)
  2. Click on ‘Tools’ from the top menu
    a1
  3. Click on ‘NuGet Package Manager’ then ‘Manage NuGet Packages for Solution…’
    a2
  4. Once the manager window pops up, search for ‘chutzpah’
  5. The results should show ‘Chutzpah – A JavaScript Test Runner’
    a3
  6. Install this NuGet package.

 

You now have it installed and you should see the unit testing icons next to your tests. For example, I use Qunit and it looks like this.

a4

 

You will also notice if you are using Qunit that I have the ‘setup’ property in my module. This is because Chutzpah is running Qunit 1.23.1, not the latest 2.x. Therefore I would check what version testing framework you are using and if it is supported. You might want to use a different test runner or downgrade your framework.

Building with Team Foundation Server

Now I’m not going to go through how to use the TFS build definitions as this is a whole huge subject itself. However I would like to show how I got Chutzpah running on build as when researching I found only snippets scattered.

The method to do this is to run it via the command line, so I know most peoples ‘Build process templates’ will be different, but this is mine. In the build process template, I have a ‘Post-test script path’ and the arguments inputs. In these I put the commands.

a5

As you will see I have a destination to the console exe application for Chutzpah. This is downloaded with the NuGet package and so should be in the same location for everyone. For copy and pasting people here is the destination:

\packages\Chutzpah.4.3.4\tools\chutzpah.console.exe

As well as other parameters, the exe takes the directory location of where the tests are held. As the build would run from the root of the project, I have done the same. This is why the exe directory starts from packages and the arguments would also start from there. If you have one script you might put the file name at the end as well, but if you want to run all tests in a directory then only go as deep as you need.

You can test the running of this by opening the project directory in command line and running the same command. Quick-tip to get to the directory faster is to open it in File Explorer, then type ‘cmd’ in the address bar and click enter as below:

a6

Once open you can run the command like this:

\packages\Chutzpah.4.3.4\tools\chutzpah.console.exe project\JsUnitTest\

You should then get the below:

a7