|
|
|
Laravel
When speaking about Laravel, we are referring to Laravel version 4 and beyond. Laravel 4 was released in 2013 and represented a complete rewrite of the framework. The functionality of the framework was decoupled into separate components, which were managed with Composer, instead of everything being in one single huge code repository.
Laravel declares itself as a framework for rapid development with a simple and beautiful syntax which is easy to learn, read, and maintain. It is the most popular framework in 2016. According to Google trends, it is three times more popular than other frameworks, and on GitHub, it has two times more stars than competitors.
Symfony
Symfony 2 was released in 2011, but it must not be confused with Symfony 1, which was a totally different framework with different underlying principles. Fabien Potencier created Symfony 2, and the current version is 3.2, which is an incremental version of Symfony 2. Therefore, they are often called simply Symfony2/3.
Like Laravel 4, Symfony 2 is designed as a set of decoupled components. There are two benefits here: We can replace any component in a Symfony project, and we can take and use any Symfony component in a non-Symfony project. Symfony components can serve as great code examples and they are used in a lot of open source projects such as Drupal, phpBB, and Codeception. In fact, Laravel itself uses no less than 14 Symfony components. Understanding Symfony thus gives you many benefits when working with other projects.
See detailed comparisons in
- Installation
- Configurations
- Routing and Controller
- Template Engine
- Dependency Injection
- Object Relational Mapping (ORM)
- REST API
And picking the Winner: Symfony or Laravel?
React, Redux and Immutable.js are currently among the most popular JavaScript libraries and are rapidly becoming developers’ first choice when it comes to front-end development. In the few React/Redux projects that I have worked on, I realised that a lot of developers getting started with React do not fully understand React and how to write efficient code to utilise its full potential.
Some of the most common misuses of React and ways to avoid them.
Data Reference Problem
Any React app should mostly consist of small simple (or stateless function) components. They are simple to reason about and most of them can have shouldComponentUpdate function returning false.
shouldComponentUpdate(nextProps, nextState) { return false; }
Performance wise, the most important component lifecycle function is shouldComponentUpdate and if possible it should always return false. This ensures that this component will never re-render (except the initial render) effectively making the React app feel extremely fast.
Equality check for primitive data types like boolean, string and integer is very simple since they are always compared by their actual value:
1 === 1
’string’ === ’string’
true === true
On the other hand, equality check for complex types like objects, arrays and_functions_ is completely different. Two objects are the same if they have the same reference (pointing to the same object in memory).
const obj1 = { prop: ’someValue’ };
const obj2 = { prop: ’someValue’ };
console.log(obj1 === obj2); // false
Even though obj1 and obj2 appear to be the same, their reference is different. Since they are different, comparing them naively within the shouldComponentUpdate function will cause our component re-render needlessly.
Handling References
This is not an easy task if we want to do it in a nice, clean, and performance optimised way. Facebook realised this problem a long time ago and called Immutable.js to the rescue.
import { Map } from ‘immutable’;
// transform object into immutable map
let obj1 = Map({ prop: ’someValue’ });
const obj2 = obj1;
console.log(obj1 === obj2); // true
obj1 = obj1.set(‘prop’, ’someValue’); // set same old value
console.log(obj1 === obj2); // true | does not break reference because nothing has changed
obj1 = obj1.set(‘prop’, ’someNewValue’); // set new value
console.log(obj1 === obj2); // false | breaks reference
obj1 = obj1.set(...);.
See the full article here
Below is a recursive function which gives all possible unique combinations of elements in a array in all order and lengths.
Alternate 1
function getAllCombinations(arr) {
var inputArray = arr;
var resultArray = [];
var combine = function() {
var args = arguments;
var temp = [];
for (var i in args) {
temp.push(inputArray[args[i]]);
}
if (temp.length > 0) {
resultArray.push(temp);
}
for (i in inputArray) {
temp = [];
for (var j in args) {
if (args[j] == i) {
temp = false;
break;
} else {
temp.push(args[j]);
}
}
if (temp) {
temp.push(i);
combine.apply(null, temp);
}
}
return resultArray;
};
return combine();
}
Alternate 2
function getAllCombinations(arr) {
var inputArray = arr;
var resultArray = [];
var conditionNext = true;
var combine = function() {
var args = arguments;
var temp = [];
for (var i in args) {
temp.push(inputArray[args[i]]);
}
if (temp.length > 0) {
resultArray.push(temp);
}
for (i in inputArray) {
conditionNext = true;
if (args.length !== 0) {
for (var j in args) {
if (args[j] == i) {
conditionNext = false;
}
}
}
if (conditionNext) {
temp = [];
for (j in args) {
temp.push(args[j]);
}
temp.push(i);
if (temp.length > 0) {
combine.apply(null, temp);
}
}
}
return resultArray
};
return combine();
}
Alternate 3
function getAllCombinations(arr) {
var inputArray = arr;
var resultArray = [];
var checkCondition = function(args, nextIndex) {
if (args.length === 0) {
return true;
}
for (var i = 0; i < args.length; i++) {
if (args[i] == nextIndex) {
return false;
}
}
return true;
};
var applyFunc = function(args, index) {
var temp = [];
for (var i = 0; i < args.length; i++) {
temp.push(args[i]);
}
temp.push(index);
if (temp.length > 0) {
v.apply(null, temp);
}
};
var populateResult = function(args) {
var temp = [];
for (var i = 0; i < args.length; i++) {
temp.push(inputArray[args[i]]);
}
if (temp.length > 0) {
resultArray.push(temp);
}
};
var v = function() {
var args = arguments;
populateResult(args);
for (var i = 0; i < inputArray.length; i++) {
if (checkCondition(args, i)) {
applyFunc(args, i);
}
}
};
v();
return resultArray;
}
See the complete solution discussion here
Java is a programming language that was initially developed for interactive television, but over time it has become widespread over everywhere software can be used. Designed with the notion of object-oriented programming, abolishing the complexities of other languages such as C or C++, garbage collection, and an architecturally agnostic virtual machine, Java created a new way of programming. Moreover, it has a gentle learning curve and appears to successfully adhere to its own moto - “Write once, run everywhere”, which is almost always true; but Java problems are still present. I’ll be addressing ten Java problems that I think are the most common mistakes.
Common Mistake #1:
Neglecting Existing Libraries It's definitely a mistake for Java Developers to ignore the innumerable amount of libraries written in Java. Before reinventing the wheel, try to search for available libraries - many of them have been polished over the years of their existence and are free to use. These could be logging libraries, like log back and Log4j, or network related libraries,...
Common Mistake #2:
Missing the ‘break’ Keyword in a Switch-Case Block
These Java issues can be very embarrassing, and sometimes remain undiscovered until run in production. Fall-through behavior in switch statements is often useful; however, missing a “break” keyword when such behavior is not desired can lead to disastrous results. If you have forgotten to put a “break” in “case 0” in the code example below, the program will write “Zero” followed by “One”, since the control flow inside here will go through the entire “switch” statement until it reaches a “break”.
Common Mistake #3: Forgetting to Free Resources
Common Mistake #4: Memory Leaks
Common Mistake #5: Excessive Garbage Allocation
Common Mistake #6: Using Null References without Need
Common Mistake #7: Ignoring Exceptions
Common Mistake #9: Breaking Contracts
Common Mistake #10: Using Raw Type Instead of a Parameterized One
|
|
|
