Thursday, July 28, 2016

Big data is like teenage sex

Monday, March 7, 2016

UX of leaking pipes

Pipes are leaking. How can we make users don't use the faucet?

Here are 2 of many ways to stop users from using it:
1. Prevent water from coming from the faucet
2. Prevent users open the faucet
Which one do you like better?

Wednesday, July 8, 2015

Perfect way to detect page is ready without jQuery (document.ready without jQuery)

If you find yourself without jQuery and you need to detect if your page is ready, feel free to use this plain JavaScript implementation I've extracted from jQuery 1.11.3 (the latest of the 1.x.x branch at the time of writing). JSFiddle link below.

// bindReady source

 * jQuery JavaScript Library v1.11.3
 * Includes Sizzle.js
 * Copyright 2005, 2014 jQuery Foundation, Inc. and other contributors
 * Released under the MIT license
 * Date: 2015-04-28T16:19Z
var readyFired = false;

function bindReady(readyCallback) {
     * Clean-up method for dom ready events
    function detach() {
        if (document.addEventListener) {
            document.removeEventListener("DOMContentLoaded", completed, false);
            window.removeEventListener("load", completed, false);
        } else {
            document.detachEvent("onreadystatechange", completed);
            window.detachEvent("onload", completed);
    // Handle when the DOM is ready
    function ready() {
        if (!readyFired) {
            // Make sure body exists, at least, in case IE gets a little overzealous (ticket #5443).
            if (!document.body) {
                setTimeout(ready, 1);
            // Remember that the DOM is ready
            readyFired = true;
            // Time to call back
            if (readyCallback && typeof (readyCallback) === "function") {
     * The ready event handler and self cleanup method
    function completed() {
        // readyState === "complete" is good enough for us to call the dom ready in oldIE
        if (document.addEventListener || event.type === "load" || document.readyState === "complete") {
    // Catch cases where $(document).ready() is called after the browser event has already occurred.
    // we once tried to use readyState "interactive" here, but it caused issues like the one
    // discovered by ChrisS here:
    if (document.readyState === "complete") {
        // Handle it asynchronously to allow scripts the opportunity to delay ready
        // Standards-based browsers support DOMContentLoaded
    } else if (document.addEventListener) {
        // Use the handy event callback
        document.addEventListener("DOMContentLoaded", completed, false);
        // A fallback to window.onload, that will always work
        window.addEventListener("load", completed, false);
        // If IE event model is used
    } else {
        // Ensure firing before onload, maybe late but safe also for iframes
        document.attachEvent("onreadystatechange", completed);
        // A fallback to window.onload, that will always work
        window.attachEvent("onload", completed);
        // If IE and not a frame
        // continually check to see if the document is ready
        var top = false;
        try {
            top = window.frameElement == null && document.documentElement;
        } catch (e) {}
        if (top && top.doScroll) {
            (function doScrollCheck() {
                if (!readyFired) {
                    try {
                        // Use the trick by Diego Perini
                    } catch (e) {
                        return setTimeout(doScrollCheck, 50);
                    // detach all dom ready events
                    // and execute any waiting functions
// end bindReady

Tuesday, May 5, 2015

#businessanalysis for beginners. Internal motivation and struggles of BAs

Have you ever wondered who are these people who do business Analysis and why are they doing it?
I had the fortune to facilitate series of BA workshops where I got to ask questions to real-world BAs.
At the first meetup I have asked what drives them to do analysis?

After all, a good chunk of developers are trying to stay away from it, and since I have came out of that crowd, I am curious why people choose to do BA

So, here is how they have answered what business analysts love and what challenges them in BA
Motivation and struggles of BA

I can't deny the truth any longer...#businessanalysis @CoggleIt

Last 10 years I have been working as a software developer/tech/team lead/PM. I have spent seems like an eternity working with different flavors of SharePoint. I liked that too.
So, it's time to move on....
and uncover my passion in BA! I looooove business analysis! 
During years working with SharePoint I was wondering what kept me fascinated by it and I know now - ability to use platform to deliver business value quickly:
Feature tree on
  • I don't have to spend months to craft some basic and needed business processes for people who need solution, not technology per se;
  • I got to spend more time talking with people to understand their current challenges and co-create with them solution to solve and less time staring at the code.
Last year I walked away from SharePoint and started leading the custom development project.
I have successfully compensated absence of SharePoint in my life with BA activities on the project.

So year later, I am ready to shift focus in my blog - starting now, posts will be more on business analysis side and not so much or maybe not at all on development.

I am sorry SharePoint developers/administrators, I already lost bunch of you, and will lose even more.

Business analysts, I would love to connect with you and promise to share my BA experience, techniques and tools that make BA effective.

By the way, this first post featured my latest nugget in BA toolset - - an extremely useful and free! tool that helps to do not only mind mapping, but feature tree too.

This tree was a huge success in my project to visualize:

  • scope of the project;
  • priorities using colors, 
  • as well as completion of the features.

Wednesday, February 18, 2015

#APIM Dashboard. Usage report: Blocked, Failed, Other calls

Azure API Management shows the API usage report with the categorization:

Recently my client asks what are the criteria used for these categories.
And here we are:

Successful: 2XX 
Blocked: 403 and 429 
Failed: 5XX 

The rest are counted as other.

Thursday, January 22, 2015

#AzureAPIMgmt '<'quota calls="x" renewal-period="seconds"'>'. Does this allow x call in total per product, or x call per API inside the product?

Azure API Usage Quota Policy allows you define quota per product , per api , per method
The question that I have got from the client was the following:

Quota calls on the product level = x. Does this allow x call in total per product, or x call per API inside the product?

Answer: <quota calls="x" renewal-period="seconds"> allows total X amount of calls per product.


Quota per API
I have a quota setup per API.  Every 60 seconds we can call 5 times each specified APIs. If we exceeds, we get 403 Quota Exceeded
For example:
I call "Echo API" 5 times. Then I am trying to call it one more - 6th time. Failed. 403 Quota Exceeded
But I am still able to call "My Echo API" 5 times after I have called 5 times "Echo API".

Quota per Product
Now, I have modified the policy , I have put calls="5" on the product level. Every hour we can call 5 times any APIs in total per product.

For example: I call "Echo API" 3 times, then I call "My Echo API" 2 times.  Total=5. Then I am trying to call "Echo API" again. Attempt is failed. 403 Quota Exceeded


It's worth to note that you can't set less than 3600 sec renewal-period on the Product level in case you set calls limit on the product level.

One of improvements that I want to suggest to MS - is to provide error messages for Policy editor, as well as IntelliSense.

The  only indicator now that is something wrong with the policy is the fact that I can't save it . How do you know you saved the policy? It should be grey out when it's saved.