Volunteering: The Nav test

The 'Volunteer Navigation' test is designed to have a measurable technique of evaluating whether volunteering teams are headed in the right direction in our mission to create a better world.

This test's parameters were open for review and modification until 1st September 2015, after which it was frozen and used as a score-reference for any volunteering team (non-profits, for-profits, govt. units, corporates or individuals) who would like to improve or have a reference point to start with. Feel free to share your views in the comments section.

The Nav Test

You start with a score of zero and add or subtract points according to the bulleted list.

• Plus 1 if the team has a long-term commitment to improving a certain area of society. (2 minus points if they jump from one activity/area to another in less than 2 years)
• Plus 1 if the team maintains data to measure if their work really helped the beneficiaries and analyze if it could be done better by finding a way to solicit honest feedback. (1 minus point if the only data maintained is a bunch of photos, number of items donated and/or the number of volunteer man-hours. If no data is maintained, 2 minus points)
• Plus 1 if the team consults with experts in the field, for knowledge. (1 additional plus point if the team is the expert and is building knowledge that is freely shared)
• Plus 1 if the team takes pains to actually understand and solve the cause of the social problem, analyzing it from the point of view of the various factors that contributed to the problem.
• Plus 1 if when you join the team, the team informs you of their past, identifies your skills, interests and comfort-level to ensure that you contribute your best when you join them. (1 additional plus point if they educate you further)
• Plus 1 if the team has a mechanism to handle disruptive volunteers.

A very good team would score 6.
An average team would score 4.
An exceptional team would score 8.


Don't be surprised if the score of many teams go to negative numbers :-) It's good if it does, because now that they know it, they also know exactly where to improve.


Why the Nav test was created

Real volunteering is difficult & boring. Really. But it's the best way to help society.

Some creative volunteer leaders try removing some of that boredom by introducing fun activities for volunteers. It's one of the hallmarks of good leadership; but the leader also ensures that the objective of helping society is first met. The fun is brought in as a second layer...as icing on a cake.
Sad part is, that volunteers or anyone else who sees those fun activities, tend to miss out on the cake (the actual work put into helping society). So when these people try conducting a volunteering activity on their own, their first priority is to plan out the fun part, and it doesn't really matter to them if the activity really helps society or not. For some others, it's a short-term activity driven by vanity or pressure from people in authority.

It is saddening to watch people do what they think are 'acts of kindness' and yet be completely apathetic to the real social issue. 'Misguided kindness', as some call it. It's time people become aware of what they are doing and it's time to change the trend, both for volunteers who are just about to start a team and for those who are already volunteering.

What is your score on the Nav test?


To be successful as a score-tool, the Nav test needs to be put through a thorough evaluation by people who are experienced in the field of volunteering/social-work. There will be people who scoff at it, but that's what happens at the beginning of every change that goes in the right direction.

Hoping to hear from you.

The author is the creator of the Nav test, has completed Copenhagen Business School's course on Social Entrepreneurship with distinction, has led two volunteering teams and volunteers actively for social causes.

LOL

Continued from the previous LOL page

Cars for heroes

Share with this link

Festivals

Share with this link

Will be continued in the next LOL page 

 

 

Interpreting the disk usage analyzer of Linux

For anyone who has used Windows, it's just a matter of seeing the properties of a drive, and you're shown what percentage of the disk is used and which isn't. In Linux though, the sunburst is a seemingly weird representation of disk usage. It's basically a multi-level pie chart.

Thankfully, Ubuntu has the Windows style representation too...

and right-clicking nautilus to see properties also shows you disk usage.

Interpreting the sunburst

This representation isn't much good at showing you how much free space is remaining on your disk. What it's good at showing is which folders are taking up a lot of your space.

The grey circle in the middle represents the root folder of Linux. What you know as "/". The place you reach when you do "cd /". On hovering the mouse pointer over it, it shows me the root folder has 7.6GB of files in it.

The amount of space taken up by the files in root is considered 100%. This does not mean that the disk is 100% full. It means that we are just representing 7.6GB = 100%, so that if any folder in root takes up 4.6GB of space, we can say that the folder is = 4.6/7.6 = 60% of the 100%.

Reds = Folders taking up most space
Purples = Takes up lesser space than reds
Greens = Takes up lesser space than purples
Yellows = Takes up lesser space than greens

You are also shown labels of the next level of folders so that you can narrow down on which of the folders in root is taking up the most space. Hover the mouse pointer over those red spaces (I'll be hovering over the "usr" folder) and you'll see how much of space the folder is taking up.

Let's go deeper than the root folder

Now click on the red "usr" folder, and suddenly, "usr" will be shown as the root folder of the sunburst, and all other coloured semi-circles around "usr", are the child folders of "usr" and the grandchild and great-grandchild and so on....All belonging to "usr" only. No information of the "home" folder or "lib" folder etc. are shown. This is purely for "usr" and the folders contained within it.


But why are only the first few circles forming a full circle? The outer ones are just tiny circle segments. What do they mean?

Notice that the purple folder "share" appears to have 7 folders in it (app-install, pyzy, netbeans etc.) which occupy almost all of the purple space, and there's a bit of empty white space too near the app-install folder. The empty space, is not actually empty. It's full of 342 tiny little files which the disk usage analyzer isn't showing because they are too tiny, and labelling them would clutter up the screen.


Go into "share" which is the subfolder of "usr"

Click on "share", and you'll see some of those files. Also, you'll notice that "doc" is taking up the most space in "share".

See the diagram below to understand the positioning.

Red sector 2 (I'm calling it '2' from now on) is a subfolder of red sector 1 (called as '1' from now on). See how 2 is positioned on top of 1's circumference. 2 only has relevance with respect to 1. Sector 2 is not at all related to the green sector. So the amount of 1's circumference that 2 takes up, shows that 2 takes up approximately 35% space of all the subfolders of 1. The other subfolders of 1 aren't shown because there are plenty of them, but all of them are very tiny compared to 2.

So this is how the disk space usage analyzer (named "Baobab") is interpreted. Hope it's clear to you now. Finally! :-) Phew!

Pass an array to a function when you're allowed to pass only one parameter?

A colleague asked me this, and from my experience, if you pass an array to a function, there's no way for the function to know the array size because it does not know at which point of memory the array ends. So the only way seemed to be to do this:

#include<iostream>

void func(int arr[], int s)
{
    for(int i=0; i<s; ++i)
    {
        std::cout<<arr[i]<<"\n";
    }
}

int main()
{
    int a[10] = {1,2,3,4,5,6,7,8,9,0};
    func(a, 10);
}

You'd ask then how does the compiler know where an array ends when you create:
int* myArray = new myArray[10];

and then delete it with:
delete[] myArray;

Apparently, when the memory is allocated with new myArray[10], the compiler will allocate space to store the size of the array + memory to store the array itself. What is returned, is the position where the array begins.
So when it's time to delete, the compiler searches for the array size in array position - 1. This is one way to implement it.


So for ordinary arrays being passed as parameters to a function, one way is to create an array of size 11 if you actually wanted to create an array of size 10. Then use the first cell to store the array size.

#include<iostream>

void func(int arr[])
{
    int s = arr[0];
    for(int i=1; i<s+1; ++i)
    {
        std::cout<<arr[i]<<"\n";
    }
}

int main()
{
    int a[11] = {10, 1,2,3,4,5,6,7,8,9,0};
    func(a);
}


Yet another way I recently found out, is to use a template.

#include<iostream>

template <typename T, int s>
void func(T (&a) [s])
{
    for (int i = 0; i < s; ++i)
    {
        std::cout<< a[i] << "\n";
    }
}

int main()
{
    int x[10] = {1,2,3,4,5,6,7,8,9,0};
    func(x);
}

and this is how you'd do it for multiple arrays

#include<iostream>

template <typename T, int s1, int s2>
void func(T (&a) [s1], T (&b) [s2], int c)
{
   std::cout<<"a=";
   for (int i = 0; i < s1; ++i) { std::cout<< a[i]; a[i]=56; }
   std::cout<<"\nb=";
   for (int i = 0; i < s2; ++i) { std::cout<< b[i]; }
   std::cout<<"\nc="<<c<<"\n";
}

int main()
{
   int x[10] = {1,2,3,4,5,6,7,8,9,0};
   int y[5] = {5,4,3,2,1};
   func(x,y,6);
   std::cout<<"\n\n";
   for (int i = 0; i < 10; ++i) { std::cout<< x[i]; }
}

All the best!

Is there a robust mutex for interprocess locking?

This blog post is not something that shows you how to create a robust mutex for shared memory mutexes.
It tells you that if you're searching for one, then there is currently no reliable way to do it crossplatform.

If you're here, you'd already know that when a process acquires a lock and the process is killed by a user, the lock never gets unlocked and another process which is waiting to acquire the same lock, just keeps waiting.

Timed locks aren't reliable. File locking is not the way to go (but see this and this).

I did an extensive search and found that pthreads has the concept of a robust lock to solve the problem, but on trying it, the ordinary locking between processes itself is not working.


In Boost Interprocess:

Mr.Ion Gaztanaga has tried coming up with a crossplatform implementation for robust locking in Boost Interprocess, but still needs to test it fully on Windows.

If you want to take a hint on implementing it yourself, then Ion's code is the way to go.



In due time, this blog post will be outdated. Please do post the solution to the problem in the comments so that others can find it.


Btw, do you know what happens when  a foo walks into a bar? :-)

So why do we need virtual functions anyway?

For most of us, something makes sense only when we know the reason behind it.
So when our textbooks and tutorials show us something like...

class Animal {
    public:
    virtual void sound() = 0;
};

class Dog : public Animal {
    public:
    void sound() { std::cout<<"bark\n"; }
};

It just doesn't make sense. Why would I want to use such an animal class when I can simply create a separate Dog class and a Cat class? Even if the base class was a Shape and derived classes were Rectangle and Triangle, I can override the base class function without using virtual. Then why virtual?

Before proceeding, I'd like to introduce you to Initialization lists.
In C++, you are allowed to initialize values to member variables using the initialization list syntax. See this:

class Abc {
    int a;
    SomeClass* s;
    Abc() : a(10), s(new SomeClass())
    {
         //constructor body
    }
};

The value of a becomes 10 and the pointer to the newly created SomeClass is initialized into s. Note that they are not assigned to a and s. They are initialized into the member variables.


Who needs virtual?

If you're a beginner programmer, you don't really need to worry much about virtual functions. It's unlikely you'd be using much of it anyway. But if you're an intermediate or advanced programmer who has come to realize that creating software takes just 10% of your time and 90% of time will be spent in altering the code and maintaining the software through its lifecycle, then you definitely need to understand why virtual functions can help you write de-coupled, flexible, encapsulated, maintainable code.


An example:

Let's say you've written a very complex Battlefield Software which is being used on a defence truck. The software is capable of monitoring devices on the truck, communicating with the army command control center situated far away and is also capable of doing a lot of other things.

One other function of Battlefield Software is to issue a command to a gun mounted on the truck to fire ammunition. Normally, you'd create a Gun1.fire() function in Battlefield Software which directly invokes the gun's fire() function.

But what will you do when this gun is removed and a missile launcher or a gun from some other company is fitted? Those weapons have different functions for shooting, and those companies refused to change their function names to fire().

You'd have to go into Battlefield Software and change Gun1.fire() to Gun2.shoot() or MissileLauncher.launch(). Then compile everything again and test it all over again.


So what's the problem?

You tell me: "Hey no problem. I don't mind changing the function. It's just one function after all".

But you don't see the full picture here. Gun1.fire() might not be the only command that Battlefield Software uses. There might be many other places in the software where the Gun1 object instance is being invoked. There might be Gun1.calibrateGun() command, Gun1.positionGun() command, Gun1.reload() command and so many more.

Are you going to change all of them? In real-world softwares, the code becomes so complex, that it wastes a huge amount of time making corrections like these. Once such corrections are made, they have to be tested too, because you might have un-knowingly made some change and introduced a bug.


The first part of the solution...

... is to create a separate software module named WeaponController which will purely be in charge of interfacing with the weapon mounted on the truck.

Now, BattlefieldSoftware can be programmed to contain an instance of WeaponController, and to shoot a target, BattlefieldSoftware just has to call WeaponController.shootTarget().

The WeaponController class will decide whether to call fire() or launch() or shoot(). So even if a gun from a new company is brought in, the changes only have to be made to the small WeaponController program. The compilation will be faster and the testing can also be done quickly, because you are only modifying WeaponController, so you are sure there won't be any bugs introduced into the big BattlefieldSoftware program.


Implementation

Now comes the interesting part. How do you propose to implement WeaponController?
One way you'd suggest is this (it's a simple implementation just to keep it short):


class BattlefieldSoftware {
    private: 
    WeaponController* wc;
    public:
    BattlefieldSoftware() : wc(new WeaponController()) {} //initialization list for constructor         

    ~BattlefieldSoftware() { delete wc; }

    void shootTarget() { wc->shootTarget(); }
};

class WeaponController {
    private:
    Gun1* g1;
    //Gun2* g2;
    //MissileLauncher* ml;

    WeaponController() : g1(new Gun1()) /*, g2(new Gun2), ml(new MissileLauncher) */
    {}
    ~WeaponController() { delete g1; /*delete g2; delete ml*/ }

    public:
    void shootTarget() {
         if (g1 != NULL) { g1->fire(); } 
         //if (g2 != NULL) { g2->shoot(); }
         //if (ml != NULL) { ml->launch(); }
    }
};


So this is what you propose to do? Have a bunch of if conditions or switch statements which will decide which weapon to fire? Or to comment out the irrelevant weapons and re-compile?

Well, there's nothing wrong in doing it this way. It'll work without virtual functions and will work a little faster than virtual functions too, because the program won't have to refer a virtual table during runtime to decide which function it should invoke.

But notice that again, you're creating more scope for bugs and will have to repeatedly test your program because the actual program might be much much bigger than this and you can't guarantee that you have commented out all relevant lines or not unknowingly introduced some new bug.


A better way...

The better way to do it, is to create wrapper classes (WeaponGun1, WeaponLauncher, WeaponGun2) for every weapon and interface them with WeaponController.
The wrapper classes help behave like translators. When WeaponController says shootTarget(), the WeaponGun2 wrapper class will help call the shoot() function of Gun2.
Why does that help?
Because when we attach a particular gun or missile launcher to the weapon controller (we can attach only one at a time in this example), we want WeaponController to simply be able to invoke shootTarget(). If we didn't have wrapper functions, WeaponController would have to be re-programmed to invoke shoot(), launch() or fire(), everytime we attach a new weapon. We want to avoid the hassle of re-programming and re-compiling whenever we make a change.

Virtual functions to the rescue

Have a look at the new code first.

#include "iostream"

//This class is created by Gun1's company
class Gun1 {public: void fire() {std::cout<<"gun1 firing now\n";}};
//This class is created by Gun2's company
class Gun2 {public: void shoot() {std::cout<<"gun2 shooting now\n";}};

//We create an abstract class to interface with WeaponController
class WeaponsInterface {
 public:
 virtual void shootTarget() = 0;
};

//A wrapper class to encapsulate Gun1's shooting function
class WeaponGun1 : public WeaponsInterface {
 private:
 Gun1* g;

 public:
 WeaponGun1(): g(new Gun1()) {}
 ~WeaponGun1() { delete g;}
 virtual void shootTarget() { g->fire(); }
};

//A wrapper class to encapsulate Gun2's shooting function
class WeaponGun2 : public WeaponsInterface {
 private:
 Gun2* g;

 public:
 WeaponGun2(): g(new Gun2()) {}
 ~WeaponGun2() { delete g;}
 virtual void shootTarget() { g->shoot(); }
};

class WeaponController {
 private:
 WeaponsInterface* w;
 WeaponGun1* g1;
 WeaponGun2* g2;
 public:
 WeaponController() {g1 = new WeaponGun1(); g2 = new WeaponGun2(); w = g1;}
 ~WeaponController() {delete g1; delete g2;}
 void shootTarget() { w->shootTarget();}
 void changeGunTo(int gunNumber) {//Virtual functions makes it easy to change guns dynamically
   switch(gunNumber) {
     case 1: w = g1; break;
     case 2: w = g2; break;
   }
 }
};


class BattlefieldSoftware {
 private:
 WeaponController* wc;
 public:
 BattlefieldSoftware() : wc(new WeaponController()) {}
 ~BattlefieldSoftware() { delete wc; }

 void shootTarget() { wc->shootTarget(); }
 void changeGunTo(int gunNumber) {wc->changeGunTo(gunNumber); }
};


int main() {
 BattlefieldSoftware* bf = new BattlefieldSoftware();
 bf->shootTarget();
 for(int i = 2; i > 0; i--) {
     bf->changeGunTo(i);
     bf->shootTarget();
 }
 delete bf;
}



The advantage

Phew! Lengthy way of doing it, right? But see...now that I've created class WeaponGun1, I've completely separated the handling of Gun1 into the class. Whatever changes you do to Gun1, you'll only have to make changes in WeaponGun1, and have the confidence that no other class is affected.

Because of WeaponsInterface class, I can now assign any derived class to the base class pointer WeaponsInterface and because it's functions are virtual, when I call WeaponsInterface's shootTarget, the derived class shootTarget gets invoked.

Best part is, I can change guns during runtime (the code in green). This is the main advantage of virtual functions and this is why we need virtual functions.

So no more necessity to comment out code in various places when changing guns. It's now a simple and clean procedure, and adding more gun classes is also easier because we just have to create a new WeaponGun3 or WeaponGun4 class and we can be confident that it won't mess up BattlefieldSoftware's code or WeaponGun1/WeaponGun2's code.

WeaponsInterface class is the equivalent of Animal class.
WeaponGun1 class is the equivalent of Dog class.

Makes more sense as weapons class, doesn't it? :-)


One more big help:
One more little thing. In this tutorial, did you notice how you learnt something new and useful about how to structure your code so that it will be more maintainable? Well, software architects have identified many such situations and created absolutely awesome ideas for structuring code. These ideas are completely worth learning. You'll actually be impressed about how effective they are. Once you've matured a bit in programming, make sure you get a good book on Design Patterns and learn them. In real-life even if you try to use design patterns, code can get messed up due to tight deadlines, but it still helps to know those concepts.