Category: Uncategorized
Functions in JavaScript are objects
Functions in JavaScript are objects.
How to know in the browser?
Navigate to the console of the browser near you and type this simple function Person shown below and hit enter. Next, type Person followed by dot (.) see the methods on Person function. Pretty simple.
Thus the function is an object and has the methods as other objects in JavaScript.
We can call functions on function. Let’s invoke call function and see the output.
call method on function Person.Prototype object:
Objects are keyed collection/associative array that has a hidden link to the prototype object. Try the following code in any browser console and understand it.
We can access the prototype object using Object.prototype.
We can get an original object back from the prototype object using constructor (Object.prototype.constructor) property.
Pictorial representation of Object and it’s prototype object.
Oh, wait! We were talking about Function.
Like Object, Function is linked to Function.prototype.
Let me show you using Person function, it’s prototype object and their linking in the browser console.
Pictorial representation of Person function and it’s prototype object.
Some design guidelines developers need to know
- 4 Rules of Simple Design
- Domain-Driven Design
- SOLID
- Patterns
- Law of Demeter
- Tell, Don’t Ask
- POLA/S
- Design by Contract
- Feature Envy
- Cohesion
- Coupling
- Balanced Abstraction Principle
Test case structure
A commonly applied structure for test cases has
- Setup: Arrange the state of the unit under test in order to run the test.
- Execution: Act on the unit under test so that it performs the expected behavior and receive output if needed.
- Validation: Assert/Verify the outcome of execution.
- Cleanup: Restore unit under test to a pre-test state.
Test-driven development benefits
- Design first: You understand requirement first via analysis, create use cases for it. Thus, the focus is on the requirement before writing the code.
- Good enough code for now: You write sufficient code against use cases that fulfills the user requirements. You don’t write extra lines of unnecessary code.
- Avoid rework: Due to design first approach, most of the doubts are cleared before writing code hence rework is avoided.
- Developer confidence: Continous delivery of requirement in small cycles gives developer a confidence.
- Regression catching.
- Safe Refactoring: Once the code is covered by multiple tests, a developer can safely improve code structure with confidence and can focus on simple and elegant design.
- A shared understanding of the business: Tests are the live documentation that is the communication channel between you and your future version or other developers that talks about business rules.
- Clean code reminder: IMO, TDD always reminds you to make your code better than you found it. Of course, after covering your code with test, make it better.
Rest parameter under the hood…
You know the rest parameter (usually prefixed with ...) allows functions or methods to accept indefinite numbers of parameters.
This parameter is actually gathering the values from arguments and creates an array of values from it.
How? Let’s see with code using ES6 rest parameter and it’s corresponding transpiled version.
Simple snippet with rest parameter
Obviously, line 2 will print an array
[ 'Monday', 'Tuesday', 'Wednesday' ]
You wonder, How it’s an array? Let’s inspect it via
Below code is transpiled using BABEL.
Transpiled version:
Under the hood, the rest parameters are actually derived from arguments object of called function, `print`. Please notice carefully variable days on line# 5.
It’s value is set to an array whose length is equal to number of arguments passed.
Later, elements from arguments are copied to variable days (element by element from line# 8 to 10).
Another Example
In the second code snippet, please note there is a parameter multiplier apart from rest parameter ...numbers. Hence, copying will not begin from first element instead it started from second element till last one.
See transpiled version for more details.
Transpiled version
const does not mean value it holds is immutable
I see many JavaScript developers have started replacing var with const just because some linter forces them to do so.
const in JavaScript is not only blocked scope but also const variable cannot be reassigned with new content.
It creates readonly reference. It means you cannot reassign value to the const variable. It does not guarantees immutability of the content that it holds.
const person = { name: 'John Doe', age: 33};
person = { name: 'John'}
// Above line will throw Uncaught TypeError:
// Assignment to constant variable.
// However, you can change the content of object
// that is referenced by person variable.
person.age = 40;
So, If you really want to mark your object as immutable then use some other API’s like `Object.freeze`.
There are specific use cases about const variable. Make sure you are intentionally marking some variable as const and not because some linter has that rule.
The Journey Begins
Thanks for joining me!
Good company in a journey makes the way seem shorter. — Izaak Walton
Is it time to re-name “Human resources” department?
Few weeks ago, I received an email from a recruiter. The title of the email went like, “Need immediate .NET resources who can join in Blah Blah.. time”. The email kind of triggered many thoughts in my mind. Am I really a “resource”? Is that only what I stand for? If I put in all efforts in my team and company’s success, will I still be a resource for the company? and so on…
We have been hearing this word “Human resources” for a very long time now. One of the companies I worked for hired college students from a campus in huge numbers. Once these graduates would join the company, there was a separate department named “Resource management group” who would look into how to harness these resources for company business. I was one of those graduate resource. For a very long time, I had the kind of feeling which you would have on seeing a huge farm of humans in the movie Matrix. In this movie, the machines would harness these humans for their survival.
It’s a common term in traditional program management to address, people, computers, cubicles everything as resources. “Is the project delayed? Ok, no problem, put 10 more resources and complete it quickly.” We may have heard or even been a part of such conversations.
But, are we really resources? I’m not. I’m not a machine or a chair or a white board. I’m human. I have feelings, thoughts, ideas, knowledge. I get motivated, I get happy, I get sad, I have ups and I have downs. I don’t just type code. I create things, that help others, makes their life easy, things that make difference.
A company is not made by how fascinating offices they have, or how many computers they have. The most important asset for a company is its people, without it’s people, there would be nothing. Many successful companies originated in someone’s basement.
Google has moved away from the word “Human resources”. They call it “People operations”. And we all know the efforts Google takes in taking care of it’s people. And we also know the care it’s people take in keeping Google such a successful company.
I believe people in any company deserve more respect, not just for the work they do, but also because we’re humans. The culture of mutual respect, drives ownership and belongingness. These values can drive any company to great heights.