Creating Base Class in Javascript

Like programming languages such as C#.NET and other languages, base class are often required to help with application development.
So what about Javascript, how is it possible to create base class in Javascript?
The tutorial below will show a general example of creating a base class in Javascript

Step 1: First step after creating the javascript file (eg. companyinfo.js), is to first add the following code below, which will will call it, "company_styles":


var company_styles = function(spec){
 var that = {};
 return that;
}


Step 2: next we have to create a variable function. Here we called a variable function called "CompanyName":


var company_styles = function(spec){
 var that = {};
 var CompanyName = function(){
  return "My Company";
 }
 return that;
}

Step 3: next we have reference "CompanyName" function to the public function:


var company_styles = function(spec){
 var that = {};
 var CompanyName = function(){
  return "My Company";
 }
 that.company_name = function(){
  return spec.CompanyName || CompanyName();
 }
 return that;
}


Step 4: Now we would create a new variable for debugging purpose called, "debug_company_styles", which would create a new instance of "company_styles":


var company_styles = function(spec){
 var that = {};
 var CompanyName = function(){
  return "My Company";
 }
 that.company_name = function(){
  return spec.CompanyName || CompanyName();
 }
 return that;
}
var debug_company_styles = new company_styles({});


Now in Google Chrome, we can debug function called, "company_name", and we can see that the value "My Company" is returned:

Step 5: Next we will see create a new function called, "my_company_styles" just below "company_styles", which will override the function name, "company_name" as shown below. And also, "debug_company_styles" will not create an instance of "my_company_styles":


var company_styles = function(spec){
 var that = {};
 var CompanyName = function(){
  return "My Company";
 }
 that.company_name = function(){
  return spec.CompanyName || CompanyName();
 }
 return that;
}


var my_company_styles = function(spec){


var that = new company_styles({});
 that.company_name = function(){
  return "My Other Company";
 }
 return that;
}

var debug_company_styles = new my_company_styles({});


Now in Google Chrome if we debug again, and called the function, "company_name", we can see that the value "My Other Company" is now returned:

Agile Scrum - How to play

Agile Scrum - Enjoyable and productive

Agile Scrum is a great way to manage your task within a project.
Agile Scrum provides a burndown chart which keeps you on track of how much task you have completed in a graph format, and what is left remaining.

Agile Scrum should be also be flexible. For example, if estimating a task deadline, it's not always going to be accurate, but some thought should be put into the deadline. Also, for the experienced developers, we all know that our clients would 99% of the time would want some sort of change requirement to a task or a section of a project, especially if it's a huge project. Agile Scrum should adopt to some change requirements if required.

So let's start of how to play Agile Scrum.

First thing we should ask ourselves is what we need to play Agile Scrum.


So here's the main things required for Agile Scrum

1. We obviously need our developers referred as team members

2. It is recommmended to have a scrum master. Someone who monitors and keeps track of how the task is progressing in the project, and any hurdles in the way.
Generally, it is the scrum master who either always develops the burndown chart, or then either tightly monitors the burndown chart.

3. Project Manager, who mainly interacts with the scrum master.

4. White board is required for managing stories and task.

5. Each team member, and possibly scrum master is required 10 cards or papers, numbering from 1 to 10. This will be used to vote to see how much importance is required for each story, and possibly how long it would take to develop.

6. Some sticky papers (post-it note) to be used as stories to be put on the white boards.

7. It is handy to have a task management tool, such as Jira Agile Scrum project to manage Sprint Runs.

8. Each team member is a player, so like monopoly having difference characters for each player, each player should be identified as a unique character.


How to play

1. Identifying each story and sub-task

Each feature or a huge task is known as a story.
And a story can consist of many sub-task or sub-story.

First thing required is the break up the project into features (or stories).
For example, if developing a blog website, then "post" can be a feature, and "comments" could be another feature. Post can be divided into more features or stories, such as "send notifications", "verify post or approval process to approve post", etc.

We should also identify which story are required before another.
For example, "post" is required before "comments", as comments without a post does not make sense.


2. Specify sprint runs and how long should they be

sprint runs can be 1 week, or 2 weeks or 1 month.

So for example, if we have specified sprint runs to be weekly. For the first week, we will put all our story and sub-task required for that first week.
Before doing this ofcourse, we should be realastic of how many hours (or time) we can put in development each week, or we can specify how many points we can do for each week.
The difference between points and time will be explained later on below.
So for example if we have 3-4 developers, then possibly 120 points might sound fair.

Points vs Time
Time is how much hours we put into a task. For example, we might put in 4 hours of work to a specific story. Therefore we might give 3 points for that task.
Points refer to how much importance that task is. So for example, we might deploy a sql script to specific live database which might take 1 hour. But because live environment is so sensative, we might still assign it 3 points (to test if everything is working, etc.)

3.  Placing stories on the white board

Stories can be put on the sticky paper or post-it notes with the text such as, "approval process for post approval". Then all stories are to be placed on the white board in a horizontal straight line.
If we have too many stories, then put atleast all the stories for that week on the white board.
Specify each sub task for a specific story, and place that vertically beneath each story.


4. Voting and assigning stories to each team member

Now that the stories and sub-task are all on the white board, each team member and scrum master should vote on how much point each story requires.
Also, each story or sub-task should also be assigned to specific character (team member), and put that character over the story sticky paper, to easiliy identify, which story or sub-task is assigned to which character.


5. Starting the sprint run

Start the sprint run for that week (meaning start developing the sub-task or story for that week). Scrum master should be monitoring the process of the sprint run and if required, interact with the project manager to keep the project manager in the loop.


6. Retrospective meeting after the sprint run

After each sprint run, a retrospective meeting is for all team members and scrum master.
In the retrospective team members and scrum master can identify the strengths and weaknesses for that sprint run, and how to improve future sprint runs.


7. Iteration process and burndown chart

Specify the story and task required for next sprint run, then repeat steps 4 to step 6 as a continous iteration process until the project is finishes. In the meantime, the Scrum Master should be developing the burndown chart for each scrum run.

Here some more details of the burndown chart.

http://en.wikipedia.org/wiki/Burn_down_chart

Set Timeout in Nintex Workflow

In Nintex Workflow 2007 (and maybe future versions), there is no set timeout activity, so we have to do a workaround to achieve this. The current example will set timeout for 2 days for a Nintex request approval. 

Step 1: Create a ActionID in Workflow Variable



Step 2: Name ActionID, "ApprovalTimeout"

Step 3: Insert Parallel Action

Step 4: Insert Request Approval Action

Step 5: Set Action ID in Request Approval Action

Step 6: Insert Delay For Action

Step 7. Set Delay For Action to to "5 minutes" (This is set to allow time for Request Approval Action to start first)

Step 8: Insert Task Reminder

Step 9: Set Task Reminder (in this case we have set 2 reminder for each 1 day, so total is 2 reminders in 2 days

Step 10: Add End Workflow Action

Your Nintex Workflow should look like the following below