Writing Flexible JavaScript Functions

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications.

How often have we seen function grow over time with just one more parameter added for that supposed last little piece of functionality we have to add. Far too often I would imagine.  Then add in the new requirement that some of the parameters on the function need to be optional and the next thing you know you are in a world of hurt. There is a basic maxim in any software development, the only constant is change. As a result as a software writer I strive to ensure my code recognizes this maxim along with a couple of others.

Alas for JavaScript, the poor Yorick of languages we all know so well, it does not give us a lot of flexibility in the function object. Unlike other languages, even SQL, functions/methods provide much greater flexibility in there definition, including default values, optional parameters, name parameter calling, e.t.c. It would certainly be nice if we could provide a similar model to JS function calls and definitions. Many a moon a go I started developing in ExtJS and was introduced to a very simple method called Ext.apply and Ext.applyIf. In essence these methods take two objects as parameters and merge them into one. So if you call Ext.apply({a:1,b:2},{c:1}) you would get back {a:1,b:2,c:1}.  Sounds simple enough right? The applyIf works in the same fashion but makes a test in the receiving object to see if the property already exists and if so does not over write it. This is a very simple piece of code that we can look at below:

function applyIf(objectTo,objectFrom){
              if(objectTo){
                          for(var property in objectFrom){
                                      if(typeof objectTo[property] == 'undefined' ){
                                                  objectTo[propety] = objectFrom[property];
                                      }
                          }
              }
              return objecTo;
  }

So in essence, enumerate through the properties in objectFrom and if the property does not exist in the objectTo then add the property and its value from the objectFrom. So what does this have to do with functions you are probably asking? Let’s have a look at a mythical function as an example

function doSomethingCool(
              // width of element
              width,
              // height of element
              height,  
              // text of element
              text,
              // optional x and y, element type and style string
              ,x,y,elType,style){…do some stuff}

Looks simple enough but what’s with the four of optional parameters at the end of the function.  As you well know from in your function code you end up with a bunch of if statements along the lines of if(x===undefined){x=0}.  This of course gets to be a pain in the code rear. Now let’s change our function to accept to a single parameters as an object.

function doSomethingCool(config){
            config=applyIf(config,{
                          width : null,
                          height : null,
                          text : ’’,
                          x : 0,
                          y : 0,
                          elType : ‘div’,
                          style : ‘position:relative’
              })
… do some stuff
  }

So now in our doSomethingCool function we can easily default each parameter in our function and reduce the amount of if conditions to test for them.  By defaulting each of our values we also reduce the risk of errors being introduced by bad callers.

This may seem like a simple idea but it has a couple of extremely important advantages.  How many times have you had to go and look up a function you wish to call to check the order or the parameters? I would guess far too many times. Using a single parameters object order of the values in the object to not matter. But there is a far more important reason to use this method and that is in regards to the caller.  In the standard function design you would see some code calling the method like thus:

doSomethingCool(10,10,’my text to display’,undefined,undefined,’span’)

Really does not really tell you much when you look at it does it. When another developer has to go through your code the above line tells him/her absolutely nothing and forces them to go and look at the doSomethingCool function to determine what 10 and 10 is and why are there two undefined. Now lets make the same call to the function using the config object parameters:

doSomethingCool({
              width : 10,
              elType : ‘span’,
              height : 10,
              text : ‘my text to desolay’ 
  })

Looks a lot better doesn’t it! Not only is it very clear on what we are passing, we also did not need to add in a bunch of undefined definitions to get to the elType parameter. Notice also that in the above the order of object properties do not matter either.

A couple of noteworthy things about implementing your functions this way. If you need to add another parameter to your doSomethingCool function you can simply default it the default config object that is applied without any concern of impacting existing callers.  Another great benefit is code readability. How often have you had to take someone else’s code over? Now imagine reading through that code and seeing all these clearly understandable calls.  Not only does it benefit you when you need to revisit something but it will benefits the next developer who has to hit your code to make a modification.

In the next part of the series I will be exploring Crockford’s singleton pattern vs the prototypal pattern and how to merge, extend them and organize code.

Hide your JavaScript from Firebug and other Dev Tools

I write just about everything now a days in Module Pattern, ta Mr. Crockford.  However one of my biggest worries in developing web applications is other people like me.  You know, the geek that hits your web page and immediately hits F12 in Firefox to see what’s going on, what framework your using and inevitably starts doing console.log statements just for fun.  For the serious hacker, once they find those exposed AJAX methods and what to push, life can become a real nightmare for you server not to mention the developers as they feebly attempt to explain to management ‘that’s just the way it is’.

So after several days of adding to a JavaScript Coding Standards document explaining Design Patterns at my most recent job, it got me to thinking ‘how can I protect the code yet not loose any flexibility that the Module Pattern provides?‘ It’s one of those problems you think about when you go to sleep and are still going at it when you awake at sunrise and stubbornly refuse to get up despite your brain saying ‘get at it lad’ just to add to the encouragement from your bladder. Like many problems you fiddle about with code constantly hitting F5 in your browser as your brain goes into overdrive as it is fully convinced this has to be possible!  Then the solution hits you and you exclaim to yourself ‘man that’s so f’ing obvious and simple what was I thinking!!‘.  The solution is wrap your singleton in an anonymous function – duh! So here you go enjoy:

(function(){

	var myApp =function(){
		//add your application code here as you normally would
	}();

}());

Yes its that simple!  In essence wrap your application in an anonymous function.  So long as all of your child classes within myApp reference myApp.whatever then no problem.  Give it a try then hit your page with Firebug or any other dev tool and look in vain for myApp, you will not find it.

But this introduces a problem.  Your busy working on your highly complex web app and you need to be able to do console.log statements to my app. Well no problem:

(function(){

	var DEBUG = true,

	var myApp =function(){
		//add your application code here as you normally would
	}();

	if(DEBUG){
		window.MyApp=myApp
	}
}());

Now you can debug to your hearts content and when ready for the big release set your DEBUG switch to false.  So now the next issue, ‘ya that’s all very nice Keith but I NEED to expose some of my methods for consumption by 3rd parties‘.  Again very simple:

(function(){

	var DEBUG = true,
	EXPOSED_NS = 'ForTheCosumer';

	var myApp =function(){
		//add your application code here as you normally would
		return {
			DoSomething 	: function(){},
			DoSomethingElse : function(){}
		}
	}();

	// expose my public methods
	window[EXPOSED_NS]={
		doSomething 	: myApp.DoSomething,
		doSomethingElse	: myApp.DoSomethingElse
	};

	if(DEBUG){
		window.MyApp=myApp
	}
}());

So thats about all there is to it.  In my next post I will deal with another contentious issue with the Module Pattern. Code segmentation into separate files and how to get them into your now hidden application.

Cheers

Keith

O Refio, Refio, wherefore art thou Refio (ExtJS Design Patterns)

For longer than I can remember I have been writing complex data centric applications and trying to leverage JavaScript  and DOM to do more and more of the work.  In the early days, yes pre this decade, we had to do a lot of the heavy lifting ourselves.  In today’s world we have a wide range of frameworks we can choose from.  All of these provide for different object implementations with the same goal in mind.  ExtJS is the most fully fledged out framework to date but there are competitors not far behind, for example Javeline.  Like many implementations it will come down to developer adoption which is often a result of how well that company caters to developers.  But getting into why a framework gets adopted is for a future blog post.  The purpose of this post is to talk about design patterns of an application with a focus on ExtJS.  In many cases I get dropped into the middle of an application development life cycle and in most of these cases I have noted a consistent implementation which in ‘my’ opinion lacks certain elegance. 

Since I am very evidently sticking my nose out I had best explain ‘What is Elegence?’ In terms of a JS implementation the object model should provide for an obvious segmentation of functional areas that reflect their purpose and the interface itself.  Having an overly flattened object model simply makes it confusing for developers to inherit the code base and work with it.  I usually layout my base class with the following structure. 

  • .ui
    Contains all of the components that make up the base interface.  Most often this a direct pointer to the created viewport.
  • .user
    The user class holds the context of the currently logged in user and any methods for login, logout, options etc.  It will contain interface components/methods but most often these are modal dialog in nature so do not impact on UI. The user class should also provide for permission methods.
  • .remote
    The remote class is most often a function and is in charge of ALL remote calls whenever possible.  It is important that an attempt be made to push all of your remote REST calls or any server requests through a single point of entry/exit.  In some cases this is not possible, for example with a tree control or with a panel with autoLoad set, but these are special circumstances.
  • .component
    The component object is a holder for specific component objects that your interface supports. It relies on both ui and user classes.  Often I have a common or core subclass within component that provides for common functionality that is shared amongst components.
  • .util
    A catch all class for methods that support all the other primary classes.
  • .config
    I flip flop on this one frequently.  The config object is used to store configuration objects that are commonly used throughout the application.  For example default panel configs that are applied with Ext.applyIf within functions.  I flip/flop on this one because with it being exposed it opens opportunity for nosey hackers to fiddle with it and introduce behaviors.

In many cases I see very large flattened object models and exposed components because for some very bizarre reason people have not picked up on the ref property of a container config in ExtJS.  Ref is your best friend and simplifies your life.  As you may well know one of the major challenges in ExtJS or any JS application is maintaining a reference to that object you just created.  Sometimes we drop in our on ID so that we can use Ext.getCmp(‘thatDangObject’) or pre-create a id with Ext.id, add it to the config and store the id somewhere for later retrieval.  Well by using the ref function you do not need to.  For example let’s look at a standard 3 panel viewport with a North, South, Center layout. 

First off you will note __root.ui, __root is a reference to the base class of the application but I will get to that a little later.  For now you can assume that myapp.ui is now a pointer to the created ExtJS viewport object.  If you were to use FireBug and look at myapp.ui within the DOM explorer you would see under myapp.ui, _panelNorth, _panelWest and _panelCenter.  A quick comment, if you have not heard of Firebug stop reading this article, get it, learn how to use then by all means come back and read the rest. A note about my use of the underscore in the ref property.  I use this for two reasons.  One, I know that the ref name I come up with will NOT conflict with any ExtJS property and more importantly they show at the top of the list in the DOM explorer when expanding the object. 

__root.ui= new Ext.Viewport({
layout: 'border',
items: [
{region:’north’, ref:’_panelNorth’},
{region:’west:’, ref:’_panelWest’},
{region:’center’,ref:’_panelCenter’}
]});

With ref one of the very spectacular things you can do is move it up the object hierarchy by the use of ‘..\’. So for example if I had a tbar in the _panelNorth and I want to have it exist within the DOM hierarchy directly under myapp.ui I could add in ref:’..\_topTbar’ in the tbar config within the north panel.  There are cases you may want to do this but remember if you do then you loose your logical object flow in your code which means as a result you had better name it something very logical.  For example really which is better of the below two: 

                myapp.ui._panelNorth._topToolBar
                myapp.ui._panelNorthTopToolBar 

Personally I prefer the first case because that little ol’ dot tells me something directly where as in the later example I am trusting the name to indicate it.  I will defer to dot whenever I can! 

Dude it’s an object no need to wrap it more’, this is one of my favorite issues I see in ExtJS development.  Creating components that wrap ExtJS components because of the need to track some aspect of that component.  It is kind of akin to that annoying Uncle who thought it was cute to wrap a small present inside a big box that was also wrapped.  It’s not funny and it just adds waste!  Waste is the important word here.  Not only are you wasting time but you’re wasting memory and my time while I try to figure out what the hell you are trying to do.  You can add anything to an ExtJS config object and it will show up as part of that object.  Take for example the following panel config: 

__root.ui._panelCenter.add({
	xtype:’panel’,
	ref:’_panelForSomething’,
	_myProperty1:’abc’,
	_myProperty2:’def’,
	_myMethod:function(){callmyprivateMethod(this)}
})

Now when I want to get to _myProperty in this added panel I can simply say myapp.ui._panelCenter._panelForSomething._myProperty1 and I get abc.  What I often see is the reverse where a class has been created that contains the control and a lot of extra code expended to make available certain properties/methods of the container available for consumption.  If you are comfortable with the security issues of this then make use of that ExtJS object.  There is a reason they have the functions Ext.apply and Ext.applyIf, read up on them as they are another best friend of ExtJS development.  A small comment on the use of underscore!  I realize and recognize that this is not a recommended implementation according to Mr. Crockford but I would argue this point with him with some zealousness and perhaps a slight grin on my face that I am arguing with Douglas Crockford! 

I mentioned the term security and this leads me to my next point. Not everything needs to be a publicly accessible method or property. Object scope is an incredibly important aspect of any complex application design and making EVERYTHING scoped at the object level is just asking for some pimple faced annoying genius kid to go nutty on your application in Firebug and post it up to the world in some sense of accomplishment over your lack of thinking!  This is where ‘design patterns’ come in, there are many, most notably Douglas Crockford’s. It is Crockford’s implementation that is used witin ExtJS for components. I could probably dedicate an entire book or a least a lengthy blog post to JS design patterns for the purposes of this discussion I will outline two that I use primarily.  The first is a basic class that one instance of will be created for the purpose of service the application. 


function myClass(scope){

	// private variables
	var _me = this;			// internal reference
	var __root = scope		// constructor reference
	var pTermLength = null		// exposed property

	// private methods
	function doSomething(){};

	// shared methods
	function pIAmASharedMethod(){};

	// shared property setters/getters
	function pSetTermLength(v){pTermLength=v};
	function pSetTermLength(){return pTermLength};

	// public methods/properties
	this.doSomething=pIAmASharedMethod;
	this.getTermLength=pGetTermLength;
	this.setTermLength=pSetTermLength;
	this.letItAllHangOut=new Number(1)
}

Notice that in this class we only have 3 exposed or public methods and one exposed variable name.  I like to have my public methods point to private functions.  This allows for internal/private functions to call them directly without the use of the this reserved word.  It also means that your exposed methods and properties are simply pointers.  When using this style of implementation it is important that you come to a consistent naming convention on the function and variable declarations. With regards to variables the basic rule of thumb is you should not let them hang out there publicly but rather create public setter and getter methods.  If the variable has a direct impact on the behavior of the class and typing is important then don’t just let it hang out there for consumption and override. Using a getter/setter implementation allows for you to check type and value scope of the var before fubarring your class.  Now I will fall back to Mr. Crockford and his implementation which is slightly different and serves a different purpose.  Remember the above example is for a class that will behave more like a singleton. ‘Why not a singleton’ you ask, well I will get to that next.  Mr. Cockford would say the above implementation should be done thus: 


function myClass(scope){

	// private variables
	var _me = this;			// internal reference
	var __root = scope		// constructor reference
	var pTermLength = null	// exposed property

	// private methods
	function doSomething(){};

	// shared methods
	function pIAmASharedMethod(){};

	// shared property setters/getters
	function pSetTermLength(v){pTermLength=v};
	function pSetTermLength(){return pTermLength};

	// public methods/properties
	return {
		doSomething : pIAmASharedMethod,
		getTermLength : pGetTermLength,
		setTermLength : pSetTermLength,
		letItAllHangOut : new Number(1)
	};
}

Note that in this case that when creating an instance of the class it returns an object which in essence does the same thing as the earlier class.  The difference is that the return statement returns an object which is in essence a singleton or in this case a singleton expressing the instance of the object.  My problem is that a singleton implementation is extremely limiting in its internal scope referencing.  You must follow the object convention of using commas and can NOT have locally scoped variables within the return object.  The argument would be that you should not have locally scoped variables within the returned object but I feel that is limiting.  This leads me to the second style of class implementation and for this let’s try and use a real world example to show why.  Let’s assume we have an application with a standard viewport.  On the left is a tree in which a bunch of users are listed.  In the center panel we have a tabpanel implementation.  When the user selects a user in the tree we have to create a new tab panel for that user.  Obviously then we are going to have a class that manages the interface for the selected user in the tab panel.  In Mr. Crockford’s implementation we would have a class which we would create an instance of and part of its initialization would be to create the interface.  Problem here though is we now have to write a bunch of code to manage the instances of user we have created.  Where should that code go then within are architecture?  Logically it should go in the user class itself but that class is only designed to manage an instance of a user not instances. 

Remember way back in this article I had a child class of off base entitled component.  Well this is where out component would go.  Let’s look at the code for our user class that manages multiple instances: 


function myClass(scope){

	// private variables
	var _me = this;			// internal reference
	var __root = scope		// constructor reference
	var pTermLength = null	// exposed property
	var instances=[];

	// private methods
	function doSomething(){};
	function createInterface(instance){
		// create the interface for the instance and store
		instances.push(__root.ui.center.add(instance.config))
	}

	// shared methods
	function pIAmASharedMethod(instance){};
	function pcloseAllUsers(){
		Ext.each(instances,function(o){
			__root.ui.center.hideTabPanel(o.id)
		})
	}

	// shared property setters/getters
	function pSetTermLength(v){pTermLength=v};
	function pSetTermLength(){return pTermLength};

	// public methods
	this.closeAllUsers=

	// start component
	this.component=function(config){
		var _me=this;				// pointer to this instance
		var myTermLength=1			// local instance variable

		function initialize(){
			createInterface(_me)
		};
		this.config=config
		this.doSomething = function(){pIAmASharedMethod(_me)},
		this.getGlobalTermLength = function(){return pGetTermLength()},
		this.setGlobalTermLength = function(v){pSetTermLength(v)},
		this.getTermLength=function(){return myTermLength},
		this.setTermLength=function(v){myTermLength=v}
		this.letItAllHangOut = new Number(1)		

		// init instance
		initialize();

		return _me;
	}; //-> end component
}

Notice a couple of things: 

  1. Initially we created a single instance of this class with myapp.component.user=new myClass(this) where this is a pointer to the root of our application myapp.  This means that the class can now get to any of our child classes, such as ui via the locally scoped variable __root.
  2. When we want to create a new user interface we call new myapp.component.user.component({some config})
  3. The component creates a locally scoped variable entitled _me that points to its self. On creation the internal initialize function is called which in turn calls the base class createInterface function and passes an instance of its self.
  4. Since createInterface is passed a pointer to the instance and instance has a public property that points to the passed config our createInterface method in the base class can now say create the tab panel using the passed instance.config.  The createInterface stores a pointer to it in a LOCALLY scoped array.
  5. When creating the component it returns a reference to itself for further manipulation.

Now a couple of other things.  Let’s assume that the config we pass to the component creation contains a ref value, for example it is set to ‘userABC’. Now if we want to get to it publicly through our object hierarchy it would be myapp.ui._panelCenter.userABC.  This of course would only get us to the ExtJS component.  Now is where things can get a bit confusing and there are several approaches you can use depending on your requirement. 

For arguments sake let’s assume you want to be able to get to that control directly then you could do this.  Remember you can add anything to that config! 


// start component
	this.component=function(config){
		var _me=this;				// pointer to this instance
		var myTermLength=1			// local instance variable

		function initialize(){
			createInterface(_me)
		};
		this.config=config
		config._doSomething = function(){pIAmASharedMethod(_me)},
		config._getGlobalTermLength = function(){return pGetTermLength()},
		config._setGlobalTermLength = function(v){pSetTermLength(v)},
		config._getTermLength=function(){return myTermLength},
		config._setTermLength=function(v){myTermLength=v}
		config._letItAllHangOut = new Number(1)		

		// init instance
		initialize(config)
	}; //-> end component

Now we have added our public component methods as part of the config of the ExtJS object.  So now I can say myapp.ui._panelCenter.userABC._doSomething() 

The advantage of doing this is of course the base user class when enumerating through its array of component instances can access each of the public methods of each since they are part of the ExtJS component. 

How you decide to implement these types of components comes down to what your needs are.  Questions such as does this need to be accessible from other classes, what are the security risks of being public exposed, do I need a component or will a singleton do?  Should my controller base class provide all the functionality needed? 

In my next post I will discuss the overuse of Ext.extend and Observable. When to use it and when to not use it. 

One last thing to think on… config.instance=_me!!  Now you’re going down the rabbit hole and saying to yourself ‘I should have taken the blue pill’  Try it and see what you see in Firebug DOM J 

Until then….cheers 

Keith Chadwick

Drive your site with a JS Singleton

Over the past years I have created far too many web sites that I can honestly recollect.  Some were great, some were not but what all of them had in common was a lot of JavaScript.  Way back in the early days and I’m talking about the 90’s, we all enthusiastically created our sites mixed in with a jumble of JS functions.  Many of us in those days thought it so cool to be doing rollover functions and preloading images with JS functions and all other sorts of funky stuff.  However, over time as sites became more complex the JS code started to look like spaghetti and was difficult to maintain.  In comes the JS Singleton to the rescue.  Continue reading

Looks like Mattamy Fairwinds Phase 5 is done!

This post may seem completely out of context for this blog and it is indeed.  However I am writing it because the other blog I ran, mattamyfairwindsphase5.wordpress.com was taken down about 18 months ago.  I feel that it is important for purchasers of homes from Mattamy in Fairwinds Phase 5, the few that remain, know why.

This is a long story but it’s necessary for everyone to see it in its entirety since the aforementioned blog was taken down.  In May 2008 I plopped down 25K, yes Twenty Five Thousand Dollars, on a new home being built by Mattamy in Kanata.  In early August we got a letter from them stating that construction had been delayed due to permit issues with the city of Ottawa and the province of Ontario.  By the way our original closing date was March 3rd 2009, if memory serves me correctly.  Upon receiving the letter I of course immediately called Mattamy for further information from their sales office/front line PR person.  She was a very pleasant young women who could offer me no more information and I did feel sorry for the position she was in as I imagined she was getting inundated with calls.  During the conversation I asked her when Mattamy would be providing up a follow up letter and she stated most likely sometime in October/November.  I was a little put back that they were not going to provide me, the customer, any more information for another 3 or 4 months while my money was sleeping in their bank account.  So I suggested to her that perhaps they could start a blog to provide at a minimum weekly updates, or hold an information meeting in short order, something at least.  The young women said that was a good idea and would feed it up the food chain. Continue reading

The OO Beer Case Analogy

Sometime ago I had a email conversation with a newbie programmer.  The topic of the conversation eventually led to Object Oriented programming.  Having done a fair amount of teaching over the years I have always fallen back on the beer bottle, beer case analogy which for some strange reason programmers, who are majority male, seem to get instantly.  Given this I thought it would be kind of neat to throw it out to the world with great trepidation.  Remember that this analogy is to explain the basic principles for a newbie trying to get to grips with the concept which may seem obvious and natural to many of us but to newbies is certainly not.  So without further adue ‘The  OO Beer Case’ directly from the email exchange:

Object Oriented programming is a conceptual model that can be applied to ANY language that supports it. Therefore regardless of the language you learn OO in you can apply it. OO is in essence very simple at its core and I shall give you a real world example I often use when I have taught. Imagine that your object is a case of beer. The beer case has many properties, such as color, width, height etc. It also has several methods, like open case, close case or getCountofBeer. Now we have a class called beer. We create many instances/copies of beer and then call the method on beer case called add and we pass that method a beer object. This results in the beer being added to the case. The beer of course has properties like width, height, weight, color etc and methods such as open. Now since a beer is based on a base class that we create instances of, if I ‘prototype’ a method or property into that beer base class then ALL existing beers that have already been created automatically get that new method or property we added to the base class. So from a OO perspective the beer case object ‘inherits’ X number of beer objects. Now suppose your fridge is an object and it can inherit multiple beer case objects. So in coding terms you could have this:

var fr = new Fridge()       // create a fridge
var bc = new BeerCase()     // create a beer case
var br = new Beer()         // create a beer
bc.add(br)                  // add the beer to the beer case
fr.add(br)                  // put the beer case in the fridge
fr.open()                   // open the fridge
// Get beer case number 1 from the fridge and call the beer case method get beer 
// and get the first beer and call the method open on the beer.
// This returns beer liquid to the variable getMeABeer
var getMeABeer = fr.beerCases[0].getBeer[0].open()
getMeABeer.drinkIt()             // drink the dam beer

This is the essence of OO and the above example is JS syntax.

So there you have it, the OO Beer Case analogy. Hope you enjoyed it.

Cheers
Keith

What makes a Rich Internet Application (RIA)

Recently I had a discussion on LinkedIn that was spurred by the question ‘How Do I learn JavaScript’.  The conversation took place in the RIA group so the context of the question was learning JavaScript to level to build RIA’s.  During the conversation thread there were a lot of individuals making the argument about Flash/Flex, Silverlight and Java applets are the only true platforms that support the creation of RIAs.  While this may have been the case several years ago in today’s world JavaScript frameworks have been making huge inroads into RIAs.  According to Wikipedia an RIA can be defined as:

Rich Internet Applications (RIAs) are web applications that have many of the characteristics of desktop applications, typically delivered either by way of a site-specific browser, via a browser plug-in, or independently via sandboxes or virtual machines.[1] Adobe Flash, Java and Microsoft Silverlight are currently the three top frameworks, with penetration rates around 95%, 80% and 45% respectively. Continue reading